A Lightweight UDP Transfer Protocol for the Internet Registry Information Service
draft-ietf-crisp-iris-lwz-08

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    crisp mailing list <crisp@ietf.org>, 
    crisp chair <crisp-chairs@tools.ietf.org>
Subject: Protocol Action: 'A Lightweight UDP Transfer Protocol 
         for the the Internet Registry Information Service' to Proposed 
         Standard 

The IESG has approved the following document:

- 'A Lightweight UDP Transfer Protocol for the the Internet Registry 
   Information Service '
   <draft-ietf-crisp-iris-lwz-09.txt> as a Proposed Standard

This document is the product of the Cross Registry Information Service 
Protocol Working Group. 

The IESG contact persons are Ted Hardie and Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-lwz-09.txt

Ballot Text

Technical Summary
 
   This document describes a lightweight UDP transfer protocol for the
   Internet Registry Information Service (IRIS).  This transfer protocol
   uses a single packet for every request and response, and optionally
   employs compression over the contents of the packet.
 
Working Group Summary
 
 There was consensus in the working group to publish this document.  There
were
 comments during IETF Last Call, and the doucment has been updated.
 
Protocol Quality
 
 This document was reviewed for the IESG by Ted Hardie. April Marine is
the document Shepherd.

Note to RFC Editor
 
Reference [10] in the document, to RFC 1166, documents the origin of
the convention cited in the text, but it is not needed to implement this
document or understand the convention.  Please create an INFORMATIONAL
references section in the draft and move it there.

In Section 4:

OLD
   If a client does not know the path MTU or does not use the packet
   size recommendations above, the client MUST allocate or have
   allocated dedicated network resources that will ensure fairness to
   other network packets and avoid packet fragmentation.

   For retransmission of requests considered to be unanswered, a client
   SHOULD retransmit using a timeout value initially set to 1 second.
   This timeout value SHOULD be doubled for every retransmission, and it
   a client SHOULD not retransmit any request once the timeout value has
   reached 60 seconds.  If the next query the client sends is to the
   same server, it SHOULD start with the last timeout value used.

NEW

   For retransmission of requests considered to be unanswered, a client
   SHOULD retransmit using a timeout value initially set to 1 second.
   This timeout value SHOULD be doubled for every retransmission, and it
   a client SHOULD not retransmit any request once the timeout value has
   reached 60 seconds.  

Also in Section 4:
OLD

    Finally, if a client intends multiple requests to the same server in
   a short amount of time, this protocol offers no real advantage over
   IRIS-XPC [9].  In such a case, IRIS-XPC should be used as it would be
   similarly effecient and would offer greater reponse sizes and allow
   better security.

NEW
   
   Finally, if a client intends multiple requests to the same server in
   a short amount of time, this protocol offers no real advantage over
   IRIS-XPC [9].  In such a case, IRIS-XPC is RECOMMENDED to be used as
   it would be similarly or more efficient and would offer greater
   reponse sizes and allow better security.

RFC Editor Note