Ben,
Tx for the review and follow-up.
I've added you to the acks in the rev of the
draft I plan to post shortly, which takes account
of comments from you & some minor editorial
comments off list during IETF last call.
Over & Out.
Cheers
Bob
At 21:41 20/07/2010, Ben Campbell wrote:
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
________________________________________________________________
Bob Briscoe, BT Innovate & Design
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf