Eric, Ok. Done and posted as version -06.
Thanks, Alia On Wed, Jan 7, 2015 at 4:09 PM, Eric Gray <[email protected]> wrote: > Alia, > > > > I’m happy with not changing the text further in section 5 > and I would > > appreciate it if you make the minor change to the introduction. > > > > So it looks like we have converged… > > > > -- > > Eric > > > > *From:* Alia Atlas [mailto:[email protected]] > *Sent:* Wednesday, January 07, 2015 3:55 PM > *To:* Eric Gray; Alia Atlas > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected] > *Subject:* RE: [RTG-DIR] Routing directorate review of > draft-ietf-i2rs-problem-statement > *Importance:* High > > > > Hi Eric, > > > > Responses in-line below (but with agreements removed). > > I’ll push out the slightly modified version as soon as I hear back from > you. > > > > Thanks again, > > Alia > > > > > > *From:* Eric Gray [mailto:[email protected] <[email protected]>] > > *Sent:* Wednesday, January 07, 2015 11:14 AM > *To:* Alia Atlas > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected] > *Subject:* RE: [RTG-DIR] Routing directorate review of > draft-ietf-i2rs-problem-statement > > > > Alia, > > > > Hope everyone enjoyed the holidays. > > > > Responses in-line *below*… > > > > *From:* Alia Atlas [mailto:[email protected] <[email protected]>] > *Sent:* Tuesday, January 06, 2015 5:29 PM > *To:* Eric Gray > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected] > *Subject:* Re: [RTG-DIR] Routing directorate review of > draft-ietf-i2rs-problem-statement > *Importance:* High > > > > 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. > > > > *Changing the section title helps. The issues that remain are less > significant* > > *when considered as “aspects to be considered.”* > > > > *I wanted to avoid being pedantic, but one example (now more minor) is as* > > *follows:* > > - *1st paragraph uses the phrase “describes required aspects”* > > - *the 1st list item (multiple simultaneous asynchronous > operations),* > > *however, says that a single application should be able to …* > > > > I am well used to pendatry ;-) > > > > *Without the reference to RFC 2119, “should” may be ambiguously > interpreted* > > *according to standard English as something likely but not required.* > > > > *I think what was probably meant in this case is that protocol is required > to* > > *support applications that perform multiple concurrent operations (which > is* > > *something we believe applications should be able to do).* > > > > *The current text is not explicit about this as a protocol requirement, if > that is * > > *what is intended, instead making the protocol requirement implicit based > on * > > *the way that we believe applications would likely use it.* > > > > *There are similar issues with “High Throughput”, “Low Latency” and > “Multi-* > > *Channel.”* > > > > *One advantage of referring to RFC 2119 is it makes “should” less > ambiguous,* > > *and defines this term (and other terms) as “requirement levels.”* > > > > *But I am okay with leaving this as is, because of the heading change. > Most* > > *people will be able to figure out what is meant, eventually. **J* > > > > I think so also. This is describing what the solution should look like – > not giving the > > detailed protocol requirements. > > > > > > 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. > > > > *Single-sentence paragraphs are quite common.* > > > > *See, for instance the earlier paragraph in the latest draft that reads > “This draft * > > *will expire on July 10, 2015.”* > > > > *Again, I was trying to avoid pedanticism. Sigh.* > > > > *More important in either prose or specification is that a paragraph > represents a* > > *single block/concept in whatever it is you are trying to construct.* > > > > *Even in prose, if you have an opening sentence that introduces two things > you* > > *want to talk about, then either both of them or neither of them should be > in* > > *the same paragraph. For prose, this is mostly about flow.* > > > > *In specification, it is slightly more important. A reader who is > skimming the * > > *introductory text before plowing into the salient parts of the > specification is* > > *likely to actually miss the point you’re making about scale because it’s > buried* > > *in the paragraph that introduces issues with both scale and complexity.* > > > > *If scale were important, it probably would be in a separate paragraph.* > > > > *Of course, you could (in prose anyway) do this deliberately as a way to > place* > > *greater emphasis on the second point, sort of along the following lines:* > > > > *“There are two major kinds of ideas that we can expect to encounter in > our* > > *discussions: good ideas and bad ideas. Bad ideas are obviously something* > > *we want to quickly dispense with.* > > > > *“Good ideas, on the other hand, should be …”* > > > > *In my opinion, use of this sort of literary device in a specification > would be just* > > *a bit inappropriate. If the text is not worth emphasis, leave it out.* > > > > I do think it is worth the emphasis and agree that there is almost > parallelism in > > the text deliberately. I just didn’t feel it was necessary, but if you > feel strongly > > enough to write many paragraphs about it, I’ll change it. > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
