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

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
Marcos

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