Editor's note: These minutes have not been edited.
Minutes of the FIND Working Group
35th IETF, Los Angeles
March 6, 1996
Co-Chairs: Patrik Faltstrom, Roland Hedberg Mailing list: find@bunyip.com
Subscribe: find-request@bunyip.com
In body of message "subscribe"
Reported by: Sally Hambridge, Intel Corporation
Patrik introduced Roland as the new co-chair. There was no discussion on the minutes of the meeting at the 34th IETF in Dallas. Charter revision was postponed to the end of the meeting, but Patrik went through the milestones:
- We have a current draft: draft-ietf-find-cip-00.txt - The indexing protocol has been published from WHOIS++ work:
RFC 1913.
- The group missed on having the 3 papers for Client Interface,
Server Interface, and Server Engine.
The current paper (cip-00) has a few changes since March 95 - there is a little more on tokenization. What we need is a minimal set of requirements with the "cool features" to be added later.
There was discussion on whether all servers in the mesh had to speak all protocols to be able to direct a client to all sorts of data. The CIP allows a client to use native code to go to a server to respond in the same protocol about the location of a service. The client can then go to that service. In order that all servers do not have to speak all protocols, there will have to be gateway servers. Clients may also have to advertise what protocols they are able to accept. (This may be an optimization.) There are problems with URL referrals in replication and caching. We will need to devise a scheme which either limits indexing to orginals or has the ability to de-dup the data. We discussed whether the mesh model was the correct one, and the decision that it was - for scalability.
We discussed the Data Changed Template:
# DATA-CHANGED
Version-Number: 2.0
Modification-Date: 199603041625
DSI: 1.3.6.1.4.1.1375.1
Host-Name: pollee-hostname
Host-Port: 63
Best-Time-Next-Poll: 199603050100
Window-Size: 3600
Authentication-Type: Password
Authentication-Data: xxxxxxxx
# END
If we consider Server A to be the server with the data and Server B to be the polling server, the Data-Changed Template is what A sends to B when it has data to be updated.
Main revisions here include the DSI - or Data Set Identifier. This is present in case the server with the data has several index sets it owns. The DSI is the Enterprise Number registered with IANA The polling window gives the best time for the start of an update in GMT, and the window size is the time in seconds of that polling window. Note that although Server A gives the best time for polling, Server B still makes the decision of when it polls. We were strongly informed that passwords would not be sent in the clear, and we had to work on the authentication mechanism. We had a long discussion on the problems involved with Server A sending multiple DATA-CHANGED notices between polling, and decided that the draft has to strongly recommend against Real-Time updates. (That is, in not sending a change notice for each change made in the data.)
There was a long discussion about assigning Reference Numbers to DATA- CHANGED Notices as a way to reference individual changes. Although a lot of the group thought there would be advantages to referencing specific changes, the added complexity of this was decided to be unwieldy. (Was it mandatory or optional, did Server B have to return it if Server A sent it, did this kind of incremental update really matter.) The group decided that if a reference number was needed that the Modification-Date could be used.
Version of the DATA-CHANGED TEMPLATE agreed on: # DATA-CHANGED
Version-Number: 2.0
Modification-Date: 199603041625
DSI: 1.3.6.1.4.1.1375.1
Host-Name: pollee-hostname
Host-Port: 63
Best-Time-Next-Poll: 199603050100
Window-Size: 3600
# END
We then discussed the Poll Template. This template is sent from Server B to Server A at the beginning of the polling session: # POLL
Version-Number: 2.0
Charset: UNICODE-1-1-UTF-8
Type-Of-Poll: CENTROID
Tokenization-Type: Tokens
DSI: 1.3.6.4.1.1375.1
DSI-Description: Bunyip
Host-Name: polling hostname
Host-Port: 63
Authentication-Type: Password
Authentication-Data: xxxxxxxx
# END
This template gives the type of Poll and the Attribute-Value pairs associated with that poll. Note that the DSI and DSI description are both present. We still need to do appropriate authentication work, so the Authentication-Type and Authentication-Data Attribute-Values pairs were removed. Since the Host-Name and Host-Port were part of the authentication method, they were also removed. Some method needs to be added back in! We discussed the implication of a Timestamp. If there was no timestamp, it would mean that Server A needed to send Server B the entire index (for disaster recovery, for example). A Timestamp would mean to send everything after that time.
Final version:
# POLL
Version-Number: 2.0
Charset: UNICODE-1-1-UTF-8
Type-Of-Poll: CENTROID
Tokenization-Type: Tokens
DSI: 1.3.6.4.1.1375.1
DSI-Description: Bunyip
# END
We moved to the Centroid-Changes Template. This is what Server A sends to Server B as the update.
# CENTROID-CHANGES
Version-Number: 2.0
Charset: UNICODE-1-1-UTF-8
Type: CENTROID
Tokenization-Type: Tokens
DSI: 1.3.6.1.4.1.1375.1
DSI-Description: Bunyip
URI: WHOIS://hostname/....
URI: LDAP://hostname/....
Authentication-Type: Password
Authentication-Data: xxxxxxxx
# BEGIN TEMPLATE
Template: USER
# BEGIN FIELD
Field: NAME
Data: Patrik
- FaI/ltstroI/m
- David
- Holmes
# END FIELD
# END TEMPLATE
# END CENTROID-CHANGES
The new information here includes the DSI information which, even if clients don't understand it, it should be present. URIs now give the information about the locaton of the data in the DIT. We decided the Timestamp of the Centroid needed to be added and that index changes to the timestamp should be delta. Once again, the Authetication Attribute-Value pairs were deleted with the caveat of some other authentication mechanism to be added. There was a question about how the indexing server knows whether the data is to be added or deleted. We need experience with implementation to tell tradeoffs in index size, number of false drops, update frequency, etc. Deferred to the list was discussion of each client knowing how to talk to each server - for lack of Real Time Cogent Ability. Version which still needs work:
# CENTROID-CHANGES
Version-Number: 2.0
Charset: UNICODE-1-1-UTF-8
Type: CENTROID
Tokenization-Type: Tokens
Timestamp-of-Centroid: 199603030100
DSI: 1.3.6.1.4.1.1375.1
DSI-Description: Bunyip
URI: WHOIS://hostname/....
URI: LDAP://hostname/....
# BEGIN TEMPLATE
Template: USER
# BEGIN FIELD
Field: NAME
Data: Patrik
- FaI/ltstroI/m
- David
- Holmes
***** Add/Delete???? ******
# END FIELD
# END TEMPLATE
# END CENTROID-CHANGES
Questions from the mailing list:
Are referrals returned as URIs? Yes
How are attribute names decided? When the Server is creating a centroid
it maps attribute names as well.
What Charset? Unicode-1-1-UTF-8.
Chris Weider said there had been an IAB workshop on Charset and that he was presenting a preliminary report on that workshop in the Open IAB meeting.
Patrik asked if there was interest in continuing work on the Common Indexing Protocol within the IETF. The group decided there was interest.
