Sorry for the late response--I just got back online after being out a few days for surgery.
Your response addresses my (final) concern. Thanks! Ben. On Jul 16, 2010, at 9:29 AM, Bob Briscoe wrote: > Ben, > > At 20:47 14/07/2010, Ben Campbell wrote: >> Thanks for the response. Further comments inline. (If I don't comment on a >> point, please take that to mean "okay" :-) ) >> >> On Jul 13, 2010, at 6:13 AM, 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? >>> >>> 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. >> >> It's not entirely clear to me how the RFC index quote supports the argument >> one way or another. I was not proposing we needed to maintain the entire >> history of updates. >> >> Was the work group consensus that 3168 _already_ updated 2003 (i.e. the >> original intent of 3618 was to update 2003), and the notation of that fact >> was simply missing? Or that it _should_have_ updated 2003 but did not? If >> the first, then I agree with the proposed approach. But if the second, then >> I think you have a case of _this_ draft updating 2003 by calling out text in >> 3618 that should now apply to it. > > The first. > > Even though section 9 of RFC3168 on updates to tunnel processing > <http://tools.ietf.org/html/rfc3168#section-9> > contained two parallel subsections (9.1 & 9.2) on respectively IP in IP > tunnels referencing 2003 and IPsec tunnels referencing 2401 (IPsec), it only > included 2401 in the "Updates" header. There can be no other explanation than > simple error for omitting "Updates 2003". > > >> In particular, does 3168 contain text on how it updates 2003? Could someone >> understand how 3168 applies to 2003 by reading that document alone? > > Yes > >> Or does that text reside in this draft? > > No > > >> In any case, if you still believe it should stand as is, I will not push the >> point further. If the IESG is okay with the approach, then it's fine with me. > > I guess I ought to submit an erratum for RFC3168 and RFC4301 at the same > time, in order to add these two "Updates" headers. > > > > >>> >>> >>>> -- 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? >> >> See my response to your separate email on this subject. >> >>> >>>> Nits/Editorial: >>>> >>>> -- General: >>>> >>> >> >> [...] >> >>> >>>> -- 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." >>> >> >> It's a subtle distinction, but I'm not sure the fact that 4301 says it's >> okay necessarily represents any specific current belief on the part of the >> Security Area (But I guess the security ADs can decide that.) But given that >> such believes can change over time, and an RFC is fixed, perhaps it would be >> better to simply repeat the mention that 4301 asserts this. >> >> BTW, a quick perusal of 4301 seems to say something more to the effect of >> "administrators can decide if the risk is acceptable" rather than "the risk >> is acceptable". When you say the risk is "manageable", are you referring to >> the fact an administrator could "manage" it by turning copying off? > > ecn-tunnel has just been through SECDIR review (unscathed) precisely to > ensure this belief still holds. I also presented this draft in the Security > Area open meeting a couple of IETFs ago to try to flush out any objections > (none received), and requested objections on the ipsec mailing list (none > received). > > RFC4301 is zero-config with regard to ECN. There is no standards provision > for turning anything ECN-related off or on. > > I can't find your quotes above so I assume they are paraphrases. I think you > are referring to the para below, which says IPsec provides the ability to > control propagation of changes in ECN and DS. But 4301 only provides config > for DS propagation. At an early stage I also checked the ipsec ml discussion > from the time, and it was very clear that they wanted ECN to be zero-config > and that was how it would be. > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > o IPsec describes how to handle ECN or DS and provides the ability > to control propagation of changes in these fields between > unprotected and protected domains. In general, propagation from a > protected to an unprotected domain is a covert channel and thus > controls are provided to manage the bandwidth of this channel. > Propagation of ECN values in the other direction are controlled so > that only legitimate ECN changes (indicating occurrence of > congestion between the tunnel endpoints) are propagated. > [...continues discussion, but wrt DSCP only] > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > Thanks for checking all these aspects - but I'm pretty sure I had already > done my due diligence in these respects. > > > Bob > > > > >> [...] > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
