Rob: Hi! How are you?
I just finished reading this document. Thanks for the work! I have some comments (below) that should be easy to address. I think the major one is about the ordering of the XML attributes (C2); I’ll start the IETF Last Call once (at least) that point is resolved. Thanks! Alvaro. C1. Why isn’t an IETF namespace [RFC3688] used in the XML schema? I would strongly suggest that you use one and request it in the IANA Considerations Section. Unlike the publication protocol, this document specifies version 1 – which of course doesn’t mean there isn’t a longer history behind it, so I’m open to keeping a non-IETF namespace if that is the case. C2. Section 4.1. (Common Protocol Elements) says that “The first XML attribute in each message is a version field.”, and Appendix A. (RelaxNG Schema) reflects that. However, the examples (throughout the document) don’t reflect the same ordering. C2.1. It would be very nice if the description of the fields was in the same order as what the schema defines. For example, the schema says that for a child_request the order is: version, child_handle, tag and child_bpki_ta, but the text in 4.2.1. (<child_request/>) reverses the tag and child_handle. C3. In 4.2.2. (<parent_response/>), are the offer and referral elements mutually exclusive? What happens if the client receives a parent_response with both? If it is an error, is it considered a syntax-error or something else? Section 5. (Protocol Walk-Through) offers a hint (“Bob doesn't have to accept Alice's offer, but may choose to do so.”), but the specification is still not clear. C4. The Shepherd’s write-up doesn’t mention any XML checks done, but I suspect this step has in fact happened. Please provide details so the Shepherd can complete the writeup. C5. The example in Section 4.4. (<error/>) doesn’t include the complete child_request message which presumably caused the error. C6. I think the following references can be made Informative: RFC5280, RFC5652.
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
