Hi Eric, Thanks for your review. I really appreciate it.
On Tue, Dec 16, 2014 at 8:33 PM, Eric Gray <[email protected]> wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. > > The purpose of the review is to provide assistance to the Routing ADs. > > For more information about the Routing Directorate, please see: > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-i2rs-problem-statement > Reviewer: Eric Gray > Review Date: 12/16/2014 > Intended Status: Informational > > Summary: I have some minor concerns about this document that I think > should be resolved before before publication. The document has nits > that should also be considered prior to publication. > > Minor Issues: > ========== > > Section 5 title is "Desired Aspects of ..." but the first sentence talks > about > "required aspects ..." I believe that the authors should be consistent. Keeping required > The actual "key aspects needed" are a mixture or required and desired > behaviors. Because the draft does not refer to RFC 2119 terminology, > it is not clear if this is intended or a result of narrative style choices. > I'm not sure which ones you are reading as desired vs. required. The intent is that all are required; trade-offs do happen. > If the terminology is meant to be interpreted according to RFC 2119, > then this should be added as a reference. Otherwise, perhaps the title > of the section should be changed to: > > "Aspects to be Considered in Designing Protocol for I2RS" > Yes, slightly tweaked to "Aspects to be Considered for an I2RS Protocol" since I2RS is expecting to modify an existing protocol rather than design a new one. > In this section, in addition to "Secure Control" we may want to suggest > similar "Secure Access." Information about routing may be useful to an > attacker for other forms of attack than direct control. > True - just updated the bullet to be "Secure Control and Access". The content now reads: " Any ability to manipulate routing state must be subject to authentication and authorization. Sensitive routing information may also need to be provided via secure access back to the I2RS client. Such communications must be integrity protected. Some communications will also require confidentiality. " > Section 8 ("Security Considerations") - Minimally, this section should > point to security aspects mentioned in the preceding section. > Done and extended > Note that this section mentions "extraction of detailed router state" > which is one form of access that may both require that requests > are authenticated and that information may not be intercepted. > > NITS: > ==== > > In the Introduction, second line of the first paragraph, "With scale ..." > should start a new paragraph to be consistent with the next paragraph. > eh, not worried about the consistency given it would leave the first paragraph with one sentence. In the appendix the first paragraph should probably end in much the > same way as the second paragraph, i.e. - > > "CLI Standardization is not considered as a candidate solution for the > I2RS." > > It is not clear what we are trying to say in saying "I2RS does not involve > CLI Standardization." > Sure - changed. Thanks again, Alia
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
