[Crisp] Protocol Action: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard
The IESG <iesg-secretary@ietf.org> Thu, 15 March 2007 20:51 UTC
Return-path: <crisp-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwvI-0006EF-Lv; Thu, 15 Mar 2007 16:51:44 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwvG-00061r-PP; Thu, 15 Mar 2007 16:51:42 -0400
Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRwvD-0004mD-4U; Thu, 15 Mar 2007 16:51:42 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 108162AC5F; Thu, 15 Mar 2007 20:51:09 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HRwui-0007F0-Qv; Thu, 15 Mar 2007 16:51:08 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1HRwui-0007F0-Qv@stiedprstage1.ietf.org>
Date: Thu, 15 Mar 2007 16:51:08 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: crisp mailing list <crisp@ietf.org>, Internet Architecture Board <iab@iab.org>, crisp chair <crisp-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Crisp] Protocol Action: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard
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>
Errors-To: crisp-bounces@ietf.org
The IESG has approved the following document: - 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service ' <draft-ietf-crisp-iris-lwz-08.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-08.txt 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. _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp