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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf