[Crisp] Minutes of CRISP mtg in Washingon

April Marine <April.Marine@nominum.com> Wed, 24 November 2004 21:07 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02418 for <crisp-web-archive@ietf.org>; Wed, 24 Nov 2004 16:07:42 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4QX-0006cY-2C for crisp-web-archive@ietf.org; Wed, 24 Nov 2004 16:11:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4L7-0005H3-ET; Wed, 24 Nov 2004 16:06:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4Jh-0004Bs-SB for crisp@megatron.ietf.org; Wed, 24 Nov 2004 16:04:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02100 for <crisp@ietf.org>; Wed, 24 Nov 2004 16:04:43 -0500 (EST)
Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4Nd-0006Vm-L4 for crisp@ietf.org; Wed, 24 Nov 2004 16:08:50 -0500
Received: by shell-ng.nominum.com (Postfix, from userid 10182) id 1B5605685A; Wed, 24 Nov 2004 13:04:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by shell-ng.nominum.com (Postfix) with ESMTP id 1A1EA56854; Wed, 24 Nov 2004 13:04:14 -0800 (PST) (envelope-from amarine@nominum.com)
Date: Wed, 24 Nov 2004 13:04:14 -0800
From: April Marine <April.Marine@nominum.com>
To: CRISP WG <crisp@ietf.org>
Message-ID: <20041124130318.E54922@shell-ng.nominum.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Cc: Ted Hardie <hardie@qualcomm.com>, April Marine <april.marine@nominum.com>, George Michaelson <ggm@apnic.net>
Subject: [Crisp] Minutes of CRISP mtg in Washingon
X-BeenThere: crisp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <crisp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:crisp@ietf.org>
List-Help: <mailto:crisp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=subscribe>
Sender: crisp-bounces@ietf.org
Errors-To: crisp-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c

Thanks to Kim Davies!

Minutes of the CRISP working group
61st IETF, Washington D.C.
9 November 2004

Chairs:
     April Marine
     George Michaelson

Scribes:
     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
---------------------

* draft-crisp-iris-areg-08

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
--------------------------------------------------------

* draft-ietf-crisp-iris-dchk-01
* draft-ietf-crisp-iris-lwz-00

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.


Final Comments
--------------

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.


-- 
Kim Davies, Council of European National Top Level Domain Registries
Avenue Louise 327, B-1050 Brussels; Tel. +32 2 627 5550


_______________________________________________
Crisp mailing list
Crisp@ietf.org
https://www1.ietf.org/mailman/listinfo/crisp