On Jul 14, 2010, at 11:24 AM, Bob Briscoe wrote: > Ben, > > Looks like Gorry & I are agreeing on a way forward. Are you happy too? >
Yes, it looks reasonable to me. > And with my responses to all your other points? > I just responded to the other points in a separate email. Thanks! Ben. > Cheers > > > Bob > > At 16:09 14/07/2010, Gorry Fairhurst wrote: > >> I'd be happy with this. >> >> I'm not too worried about the "should" in lower case, this reads fine to me >> the way it is. >> >> I suspect this is however odd: >> >> /it must clearly justify this decision. >> If the inner is / >> and would be happier with /needs to clearly justify/ >> >> Similarly: >> /scheme must define a behaviour for all >> combinations of inner and outer headers,/ >> would seem better as >> /needs to/ >> >> Gorry >> >> On 14/07/2010 14:43, Bob Briscoe wrote: >>> Gorry, >>> >>> Your point is very true - S.7 complements, clarifies and extends the >>> guidance of 4774, but it doesn't change it. Given the style of RFC4774, >>> I would be happy to modify my list of edits as follows: >>> >>> * Add 'Updates 4774' to the headers >>> * Leave the line saying "This section is informative not normative." >>> * Leave RFC2119 keywords out of section 7 >>> >>> I am very wary of writing guidelines that constrain future standards >>> actions anyway. That's possibly the same reason Sally avoided 2119 >>> wording in 4774. >>> >>> In section 7 of ecn-tunnel there are a number of instances of lower case >>> 'may', 'should', required and 'must', some in contexts that could be >>> confused with normative text. I have checked through, and in all cases I >>> can use alternative phrases like 'might', 'ought to', 'can' and 'needs to'. >>> >>> Ben, are you happy with this approach? >>> >>> >>> Bob >>> >>> At 19:23 13/07/2010, Gorry Fairhurst wrote: >>>> As document shepherd, I have comments on only one of the points below, >>>> and assume the the Author changes will address the rest. >>>> >>>> The items concerns the update to RFC 4774. I interpreted the current >>>> text as "clarifications" of how to interpret the wording of RFC 4774, >>>> without a change to the recommendations of the RFC itself. That is, >>>> the wording is guidance to people using tunnels and following RFC 4774. >>>> >>>> It may seem curious that RFC 4774 does not actually provide RFC2119 >>>> guidance, but this is the way it is. Adding an RFC 2119 working to >>>> this recommendation seems to me like something we have to take >>>> seriously and evaluate in the WG - but I wonder if we actually need to >>>> do this? >>>> >>>> In summary: if this adds useful context to RFC 4774, I don't see an >>>> issue with flagging the update with the RFC-Ed. --- If it seems like you >>>> see potential value in going further, I'd like to be in the loop on >>>> that discussion. >>>> >>>> Best wishes, >>>> >>>> gorry >>>> TSVWG Co-Chair >>>> >>>> >>>> Bob Briscoe wrote: >>>>> Ben, >>>>> Thank you for your review comments from the GEN-ART perspective. >>>>> I think I have dealt with all your points in my responses, which are >>>>> inline... >>>>> There is just one outstanding question for you concerning updating >>>>> BCP4774... >>>>> At 22:23 01/07/2010, Ben Campbell wrote: >>>>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>>>> Gen-ART, please see the FAQ at >>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>>>> >>>>>> Please resolve these comments along with any other Last Call comments >>>>>> you may receive. >>>>>> >>>>>> Document: draft-ietf-tsvwg-ecn-tunnel-08 >>>>>> Reviewer: Ben Campbell >>>>>> Review Date: 2010-07-01 >>>>>> IETF LC End Date: 2010-07-06 >>>>>> IESG Telechat date: (if known) >>>>>> >>>>>> Summary: >>>>>> >>>>>> This draft is almost ready for publication as a proposed standard. I >>>>>> have a couple of procedural questions that should be considered >>>>>> first, as well as a few editorial comments. >>>>>> >>>>>> Major Issues: None. >>>>>> >>>>>> Minor Issues: >>>>>> >>>>>> -- RFC Editor request (immediately after ToC): "In the RFC index, >>>>>> RFC3168 should be identified as an update to RFC2003. >>>>>> RFC4301 should be identified as an update to RFC3168." >>>>>> >>>>>> This seems odd. I assume the intent is that this draft says that >>>>>> things from 3168 should be applied to 2003, therefore updating 2003, >>>>>> etc? If so, wouldn't it be more correct to say that _this_ draft >>>>>> updates 2003 and 3168? >>>> >>>> <snip> >>>> >>>>>> -- 7, first paragraph: "The guidance below extends RFC4774, giving >>>>>> additional guidance on designing any alternate ECN semantics >>>>>> that would also require alternate tunnelling semantics." >>>>>> >>>>>> Should this draft be listed as updating 4774? Also, you've declared >>>>>> this section non-normative. What does it mean to non-normatively >>>>>> extend a BCP? >>>>> That's a very good question/point and I would appreciate your advice >>>>> on how to proceed. My take was that this was an informational section >>>>> of a STDS RFC. So I did not include any RFC2119 language. But your >>>>> nicely succinct question throws this into better perspective. >>>>> Should I: >>>>> * Add 'Updates 4774' to the headers? >>>>> * Scrub the line saying "This section is informative not normative." ? >>>>> * Shift the RFC2119 keywords in this section to upper-case? >>>> <snip> >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >> >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
