Thanks for these careful and thorough comment. On the issue of application identifiers in the section on Mutual Authentication, the application identifiers in the archtectue are not authenticated, and are not used for authorization. So I believe the current text, which talks about the client identifier, is correct.
The other editorial and substantive comments all seem useful to me. Some are tricky enough to take us a bit of work to properly address, but they are well-taken. Trying to phrase the multi-request atomicity absence right when we don't know if we have a RestConf or a NetCONF model (or something else) will take some wordsmithing. It is something we should get right. Thanks, Joel -----Original Message----- From: Jeffrey Haas [mailto:[email protected]] Sent: Thursday, January 14, 2016 5:14 PM To: [email protected] Cc: [email protected] Subject: Review comments for draft-i2rs-protocol-security-02 Authors, As part of document shepherd work for draft-ietf-i2rs-protocol-security, I've done the following review and edits on the draft. Rather than give the typical tedious line-by-line list review, I am attaching the following files: A modified .xml, based on the published -02.xml file. It includes: - Minor textual, grammatical and structural edits. - XML comments flagged "XXX JMH" of items that require response. These non-editorial items are noted below. - rfcdiff output showing the changes covered in the .xml I am attaching. I'm happy to make the git repository this review was created in available to anyone interested. (Note that Sue and I are in the process of getting a formal I2RS github repository in order to aid in this type of work.) Hopefully the .xml changes aid your integration of the comments. Commentary: - Several pieces of quoted text varied from the source. In many of those cases I've simply copied the appropriate text directly from that source. - The direct correlation between applications and clients doesn't seem to be firmly stated in the architecture. I think this document may be stretching a bit by doing so. I suggest tightening up that wording. - Messages are referred to as protocol items with regard to identifier requirements. I think this may be incorrect, as the protocol mechanisms we've discussed thus far are likely bound to sessions. Discussion may be required here. - This document notes that the data model may be tagged with the confidentiality requirements of a given set of nodes. I don't believe this has been part of our prior data model discussions and thus may represent a new requirement to convey to the netmod group. (Note that description annotation may be used, but given that the desire seems to be to impose security restrictions based upon this, that may be too weak of a mechanism.) - In the presence of such data model security requirement markup, what should the behavior be if there's an attempt to violate confidentiality requirements; e.g. using a non-confidential transport to carry confidential information? Once we've reached some conclusion on the discussion above and have produced an updated version, we should be able to proceed through the next portion of the document shepherding process. -- Jeff (acting as an individual contributor) _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
