ietf
[Top] [All Lists]

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

2010-07-02 17:14:07
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? 

-- 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?

Nits/Editorial:

-- General:

Idnits gives some warnings. Please check.

There is quite a bit of text labeled to be removed by the RFC editor. Would it 
make sense to go ahead and remove them, and save the RFC editor the work? 
(Although, I wonder, if parts of that text is useful during the review process, 
if they would not also be useful to readers of the RFC?)

4.4, first paragraph: "a complaint"

Did you mean "compliant"?

-- 5.2, last paragraph:"as they document safe practice."
 Is that _existing_ safe practice? I.e is your intent to assert implementations 
already follow these practices, safe or otherwise?

-- 5.3.1, last bullet:"… the IETF Security Area now considers copying 
acceptable given the bandwidth of a 2-bit covert channel can be managed."

Can you supply a reference for that assertion?

-- IANA Considerations

Why remove the IANA  section? It gives us useful historical info, even if, as. 
In this case, it's empty. Also, the section should probably be numbered like 
the rest.

-- 8, List Heading: "Specialist security issues:"

Did you mean "special"?

-- Section 9:

This section seems mostly redundant to the introduction.

-- Endnotes: "Editorial Comments"
 
Are these (other than the one explicitly labeled to remove) going to stay in 
the final version? If so, I personally find the usual IETF approach of 
imbedding a note inline as an indented paragraph easier to follow.

-- Appendix D (and other Appendices to be removed) 

It's probably worth directing the removal label to the RFC editor, to reduce 
any chance of it being overlooked.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf