Jari and Russ:
Version 14 of the architecture document addresses your comments as described below. Please review the diff between version 14 and 13. I welcome further comments you have. Sue -----Original Message----- From: Jari Arkko [mailto:[email protected]] Sent: Thursday, March 17, 2016 5:01 AM To: The IESG Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Jari Arkko's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Jari Arkko has entered the following ballot position for draft-ietf-i2rs-architecture-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to <https://www.ietf.org/iesg/statement/discuss-criteria.html> https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: <https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/> https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Russ Housley's Gen-ART review raised the following question and editorial comments. I believe it would be useful for the authors to think about the question at least, but I have not seen a response yet: --- Minor Concerns: Section 4.2 talks about authorization. I would expect policy to dictate that some writes come from a specific source, but it is unclear to me whether I2RS can require that a particular write request arrive on a particular channel. Is this desirable? If so, please expand the discussion of authorization to cover this point. Next Text added to section 4.2 after 3rd paragraph: While the I2RS agent allows access based on the I2RS client's scope policy, this does not mean the access is required to arrive on a particular transport connection or from a particular I2RS client by the I2RS architecture. The operator-applied scope policy may/may not restrict the transport connection or the identities that can access a local I2RS agent. Nits: Thank you for all nits: Sometimes you say "i2rs architecture", but it should say "I2RS architecture" to be consistent throughout the document. Sometimes you say "I2RS Agent" and other times you say "I2RS agent". Please pick one and use it consistently. Sometimes you say "I2RS Client" and other times you say "I2RS client". Please pick one and use it consistently. Section 3: s/ may may vary based / may vary based / Section 6.3: s/ the yang data model / the YANG data model / Section 6.4.2: some bullets have periods, but others do not. (fixed) Section 7.1: s/ Yang / YANG / (more than one place) (fixed)
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
