Last Modified: 2004-10-01
|Done||Submit requirements document as an Informational RFC|
|Done||Submit first draft of protocol (use) specification|
|Done||Submit first draft of domain registration administrative directory services required schema element specification.|
|Jan 04||Submit revised protocol (use) specification document as Proposed Standard|
|Jan 04||Submit revised draft of domain registration administrative directory services required schema element specification as Proposed Standard.|
|Mar 04||Submit first draft of IP address registration administrative directory services required schema element specification|
|Jun 04||Submit revised draft of IP address registration administrative directory services required schema element specification as Proposed Standard|
|RFC3707||I||Cross Registry Internet Service Protocol (CRISP) Requirements|
Minutes of the CRISP working group
61st IETF, Washington D.C.
9 November 2004
Kim Davies (minutes)
George Michaelson (jabber)
Status of Working Group Documents
April Marine noted that the working groups three approved documents (core, DREG and BEEP transport) are still working their way through the RFC editor queue, and hopefully will be published as RFCs soon.
IRIS Address Registry
Engin Gunduz reported on two draft revisions that had been made since the previous meetings at IETF 60. The summaries would be very similar to updates that had been sent to the mailing list already.
From -06 to -07:
- The <name> element and name searchs for networks and ASNs are back, as some considered it necessary.
- <findASNByNumber> search has been added, with parameters for specificity. As it provides a superset of the AS query, that has been removed. It is very similar to "find network", in that you can search a range.
- <language> elements have been added to <findOrganizations> and <findContacts> like DREG, which provides for other languages in queries and result sets. There is no word on case sensitivity and it is left to implementors to decide.
- "closest match" specificity has been removed, covered by the less specific query with a flag for "allowEquivelances" set to true.
- <beginsWith> and <endsWith> has been added back to <findOrganizations/AutonomousSystemsByName/NetworksByName/Contacts>
- Added <findByContact> search for ASNs, networks, and organisations by contact. This is in essence a inverse or reverse lookup.
- Added <findNetworksBySpecificity> search, which helps when multiple networks have the same addresses. Other searches don't work well in working out the parent relationships.
- The XML syntax was adapted to support these changes
- <commonName> has been added in, replacing <first/last/middleName> in <contact> result
- <email> addess to organisations.
From -07 to -08:
- A <findNetworksByNameServer> search was added.
- Normative and Informative references were split up
- Examples added for specificity searches as an appendix.
- Fixes in the examples and formal XML statements.
One key issue that is outstanding is the current reference to a recommended search root, which reads:
"The client SHOULD start every query from the IRIS server iris.nro.net and follow the referrals to find the authoritative server to actually query."
There is a concern that the IESG will not be happy with having a specific host hardcoded in the specification.
George Michaelson stated he felt uncomfortable with having a host in the specification, and would be tempted not to specify the server selection process as a defacto one will likely naturally emerge anyway.
Scott Hollenbeck echoed this feeling that it didn't seem right to include a hostname.
Ted Hardie said you could always submit the draft with the reference in, but the IESG may remove it. He said he saw the advantage of having a single root to manage the referral process, but some people may want to set up other services outside this one. He noted that an effort had recently concluded on pulling operational things out of the WHOIS specification, making it a purely technical. He believed it could be appropriate to publish a second document that documented NRO's role in bootstrapping searches, as it doesn't build a dependency into the protocol on a single root.
Andy Newton pointed out that this is not a mandate for a client to take this approach, that the ultimate resolution method is always left to the client. There is nothing preventing definition of alternative methods, and there has been a substantial discussion on identifying the correct server which arrived at the current wording.
Shane Kerr supported splitting the document, as did Andrei Robachevsky. Leslie Daigle supported it, and tossed out the possibility of making it an IANA parameter.
Marcos Sanz stated that some fallback mechanism should be specified in the document.
Cathy Murphy said she did not mind the split, but pointed to the DREG document which specifies its resolution method in the protocol specification. Andy Newton said it was hard to compare as that is not really the same thing.
Leslie Newton said the document needed a hostname that was consistent with the expected lifespan of the document. A .arpa address could be percieve as a longer term approach that is consistent with other hardcoded hostnames. Cathy Murphy said that .arpa is for infrastructure related hosts, whereas this is for a directory service. She did not know if the IAB would find that acceptable.
April Marine suggested that it needed to go to the list, and other than this issue the documents seemed ready to move to WGLC. The room supported this.
Shane Kerr quickly asked the room whether there was concern about the LLA queries. Tim Christensen noted Andy had asked for a good use case of it on the list and admits he doesn't know of one. As it is not a trivial method to implement, and there is no sense from the user community that it is either useful or dumb, it could be something that could be added at a later date if it is really needed.
IRIS Domain Availability Check and Lightweight Transport
Andy Newton presented the iris-dchk and iris-lwz drafts, which were new revisions of the iris-dchk draft presented at IETF 60. Previously, iris-dchk contained both a DREG subset that specifically only provided domain status information, as well as a lightweight UDP-based transport. These two new documents split these two functions into distinct documents.
The LWZ draft is not DCHK specific and can be used as a transport for other IRIS registry types. The draft as it stands however will be substantially rewritten, as after some consideration and implementation experience, the current approach is not ideal. The aim instead is to introduce a lightweight binary wrapper with a small header, rather than the current XML-based wrapper. The problem with using XML is it needs a seperate entry point into the upper layer of the server that is not present with the other transports. The <getProfiles> exchange also proved redundant as S-NAPTR takes care of that.
The new binary wrapper format would see the XML with a small header, with 1 octet expressing flags that convey status, packet type, compression, and errors; 2 octets for the maximum response packet size the client is willing to accept; and 1 octet for the packet length.
Ed Lewis questioned whether a 512 byte limit was hardcoded. Andy responded that in previous drafts it was 512, but now the client could say if it knew better.
Andy said he would publish a new version of the draft quickly with a view to moving it to working group last call.
April Marine noted that every document will shortly be at Working Group Last Call, except for the newly seperated AREG operational aspects draft, but that would be simple and quickly move to WGLC. She strongly recommended those who had not done so to date to review the drafts during WGLC.