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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

Quoting from the RFC Index:
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Updates xxxx refers to other RFCs that this one merely updates but
does not replace); ...
                              Generally, only immediately succeeding
and/or preceding RFCs are indicated, not the entire history of each
related earlier or later RFC in a related series.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
The consensus on the TSVWG list was that the updates should be identified in the RFC Index as follows
2003 -> 3168 -> ecn-tunnel
3168 -> 4301 -> ecn-tunnel

In the headers of this draft we have said:
Updates: 3168, 4301

But we also noticed that the RFC Index incorrectly omits to identify that these RFCs in turn already update the earlier RFCs. The note to the RFC Editor was the result of this consensus request from the TSVWG list.

[BTW, There is nonetheless text on backward compatibility between this I-D and these early RFCs in Section 6. And "Appendix A; Early ECN Tunnelling RFCs" explains the interactions.]

Summary: I propose no change on this point.


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

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

I have an -09 revision waiting to collect comments during last-call that already removes the extraneous appendices and editorial notes. These were indeed intended to save reviewers from having to refer to a lot of other I-Ds. Once we have converged on this thread I will post it.


4.4, first paragraph: "a complaint"

Did you mean "compliant"?

Tx - Also found the same error in an earlier para


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

-> "existing safe practice"


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

1. Introduction
already says:

"...Nonetheless, the latest IPsec architecture [RFC4301] considered a bandwidth limit of 2 bits per packet on a covert channel made it a manageable risk."


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

IANA have just noted that this RFC gives them nothing to do, so I intend to leave the request for the RFC Editor to delete this section. I believe this is normal practice, so the absence of an IANA section gives as much historical info as an empty IANA section.


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

Did you mean "special"?

-> "Security issues in unlikely but possible scenarios:"


-- Section 9:

This section seems mostly redundant to the introduction.

I follow the rule that the conclusions should not introduce new material, so they will naturally be redundant. My intent was for the conclusiosn to be a brief summary, while the introduction served to introduce more background material.


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

All three are already identified as for removal, not just one (and they are all already removed in the -09 I am preparing).


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

I intend to remove Appx D & E myself (already removed from -09 in preparation).


Bob


________________________________________________________________
Bob Briscoe, BT Innovate & Design
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]