Re: Gen-ART LC Review of draft-ietf-tsvwg-ecn-tunnel-08

Ben,

Looks like Gorry & I are agreeing on a way forward. Are you happy too?

And with my responses to all your other points?

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf