Qin:
Thank you for reviewing the changes to the problem statement. Sue From: i2rs [mailto:[email protected]] On Behalf Of Qin Wu Sent: Thursday, January 08, 2015 12:00 AM To: Alia Atlas Cc: [email protected]; [email protected] Subject: Re: [i2rs] Shepherd review of draft-ietf-i2rs-problem-statement-04 Thanks for addressing my comments, your proposed changes work for me. Regards! -Qin 发件人: Alia Atlas [mailto:[email protected]] 发送时间: 2015年1月7日 5:54 收件人: Qin Wu 抄送: [email protected]; [email protected] 主题: Re: [i2rs] Shepherd review of draft-ietf-i2rs-problem-statement-04 Hi Qin, Thanks for the review and taking on being document shepherd! On Wed, Dec 17, 2014 at 10:10 PM, Qin Wu <[email protected]> wrote: Hi, authors I have been selected as the document shepherd for this draft. I think this is an important draft and support publication. Having reviewed this document (v-04), I have a number of editorial comments: 1. Section 2 said: "The second critical aspect are meaningful data-models for information in the routing system and in a topology database . " There is a typo in it, Suggested editorial change is: “The second critical aspect of I2RS is a set of meaningful data-models for information in the routing system and in a topology database.” Agreed and fixed. 2.Section 2 said: " The data models should translate into a concise transfer syntax that is straightforward for applications to use (e.g., a Web Services design paradigm)." By reading this sentence, it is not clear what is translated? data model or information from the routing system? Suggested change: The data models information sent in I2RS protocol should be able to be translated into a concise transfer syntax that is straightforward for applications to use (e.g., a Web Services design paradigm). I've changed it slightly to "The data models should translate into a concise transfer syntax, sent via the I2RS protocol, that is straightforward for applications to use (e.g., a Web Services design paradigm)." The data model is in YANG - but the transfer syntax might be xml or google protobufs or... 3. Section 3, first paragraph said: "In addition, by having I2RS focus initially on interfaces to the RIB layer (e.g. RIB, LIB, multicast RIB, policy-based routing), the ability to use routing indirection allows flexibility and functionality that can't be as easily obtained at the forwarding layer." I think here we should highlight the downside of using existing mechanism. Suggest the following replacement text: “ With an I2RS interface to the RIB layer (e.g. RIB, LIB, multicast RIB, policy-based routing), this provides flexibility and functionality for route indirection of next-hops. This flexibility and functionality cannot be easily obtained at the forwarding layer, or obtain via the relevant MIB modules (for example RFC4292) which lack the necessary generality and flexibility. “ I'm fine with not highlighting the downsides more clearly. I prefer the existing text. 4.Section 4, second paragraph said: " Detailed topological state that provides more information than the current functional status is needed by applications; only the active paths or links are known versus those potentially available (e.g. administratively down) or unknown (e.g. to peers or customers) to the routing topology. " Two sentences seems disconnected, suggested replacement text as below: “ Detailed topological state which provides more information than the current functional status is needed by applications. An example of this lack of detailed information is that only the active paths or links are known versus those potentially available paths (e.g. administratively down) or unknown paths (e.g. to peers or customers) to the routing topology. “ Slightly word-smithed to: " Detailed topological state that provides more information than the current functional status (e.g. active paths and links) is needed by applications. Examples of missing information include paths or link that are potentially available (e.g. administratively down) or unknown (e.g. to peers or customers) to the routing topology." 5. Section 8: Security consideration section Would it be better to add something to say this document is problem statement draft Security considerations are not addressed in this problem statement only document. Instead it will be addressed in some protocol documents in the future. Suggested Replacement for section 8: “ Security is a key aspect of any protocol that allows state installation and extracting of detailed router state. The I2RS protocol and data models will need to define security requirements such as such as authorization and authentication levels. This document as an informational problem statement does not have any security considerations. “ As you may have seen from my email exchange with Russ Housley, I've updated the Security Considerations section to: "Security is a key aspect of any protocol that allows state installation and extracting of detailed router state. The security considerations are discussed in [draft-ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to have a separate authentication and authorization channel by which it can validate both the identity and the permissions associated with an I2RS Client. Mutual authentication between the I2RS Agent and I2RS Client is required. Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS." 6. Section 9 Reference [I-D.gredler-idr-ls-distribution] should be updated to [I-D.ietf-idr-ls-distribution] Fixed Thanks again! Alia Regards! -Qin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
