[Crisp] Last Minute Last Call Comments on lwz-06

Marcos Sanz/Denic <sanz@denic.de> Mon, 28 August 2006 17:17 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkjN-0007xT-OT; Mon, 28 Aug 2006 13:17:01 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkjM-0007qx-GB for crisp@ietf.org; Mon, 28 Aug 2006 13:17:00 -0400
Received: from smtp.denic.de ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHkjL-0006oF-6K for crisp@ietf.org; Mon, 28 Aug 2006 13:17:00 -0400
Received: from notes.rz.denic.de ([]) by smtp.denic.de with esmtp id 1GHkjI-0000R8-Ie; Mon, 28 Aug 2006 19:16:56 +0200
To: crisp@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
From: Marcos Sanz/Denic <sanz@denic.de>
Message-ID: <OF331B8A93.4BF92D8E-ONC12571D8.004FD330-C12571D8.005EEBEC@notes.denic.de>
Date: Mon, 28 Aug 2006 19:16:49 +0200
X-MIMETrack: Serialize by Router on notes/Denic at 28.08.2006 19:16:56, Serialize complete at 28.08.2006 19:16:56
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: iesg@ietf.org
Subject: [Crisp] Last Minute Last Call Comments on lwz-06
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

Dear all,

There were some comments during Last Call on the draft in the general list 
and my guess is that maybe Andy is going to do a new version with some 
additional text in the security/MTU/congestion/retry issues. Besides that, 
I think that the document is in good form and my company has implemented 
it without any problems. Here come some nitpicking remarks:

*Section 1: s/descretion/discretion/
*Section 2: s/numberic/numeric/
*Section 2: s/left most/leftmost/ (so does the RFC editor like nowadays)
*Section 3: s/prepared to accepted/prepared to accept/
*Section 3: "clients MUST NOT send packets larger than 4000 octets". 
Servers must not either.
*Section 3.1.1: s/lenght/length/
*Section 3.1.1: s/the total length of the UDP packet/the total length in 
octets of the UDP packet/
*Section 3.1.1: s/the length of the authority field/the length in octets 
of the authority field/
*Section 3.1.2: s/3 octets and/3 octets in length and/
*Section 3.1.2, 1st bullet: How realistic is that the transaction ID in 
the request could not be read due to truncation? The transaction ID 
occupies the bits in the positions 73rd to 88th!
*Section 3.1.2, 2nd bullet: s/MUST us/MUST use/
*Section 3.1.3: "The bits of the payload header are ordered..." I think 
this sentence is redundant, because terminology has been already 
introduced extensively in section 2.
*Section 3.1.3: s/bits 3/bit 3/
*Section 3.1.3: For the sake of completeness, add "If 0, the payload is 
not compressed".
*Section 3.1.5: s/comformant/conformant/
*Section 3.1.5: "...and use the <versions> element as the root element." 
That's true except for "vi" queries.
*Section 3.1.5, <dataModel>: s/IRIS registries/IRIS registry types/
*Section 3.1.5: s/PT flag/PT field/
*Section 3.1.5: One cause for sending 'vi' type is "The IRIS-based XML 
payload does not match a version the server supports." My gut feeling is 
that this shouldn't be dealt with at the transport level (neither XPC nor 
BEEP do that for instance!) and would drop this reason, but I don't have 
strong feelings about this.
*Section 3.1.7: s/interpretting/interpreting/
*Section 7.1.1: s/RFC2396/RFC3986/
*Appendix A: The same as with XPC, I'd drop all schemaLocation hints and 
temporaryReference attributes from the clients requests.
*Appendix A: s/verion/version/

Best regards

Crisp mailing list