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

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Jul 2010 16:23:48 -0500

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.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 13 Jul 2010 12:13:22 +0100

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

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

>Did you mean "compliant"?

Tx - Also found the same error in an earlier para

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

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:"

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

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

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

>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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 13 Jul 2010 19:23:13 +0100

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

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 14 Jul 2010 14:43:08 +0100

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.
>
>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.
>
>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?
>
>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,
>>>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:
>>>
>>>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>
>
>>>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:

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 14 Jul 2010 17:24:21 +0100

Ben,

Looks like Gorry & I are agreeing on a way forward. Are you happy too?

And with my responses to all your other points?

Cheers

Bob

At 16:09 14/07/2010, Gorry Fairhurst wrote:

>I'd be happy with this.
>
>I'm not too worried about the "should" in lower case, this reads 
>fine to me the way it is.
>
>I suspect this is however odd:
>
>/it must clearly justify this decision.
>           If the inner is /
>and would be happier with /needs to clearly justify/
>
>Similarly:
>/scheme must define a behaviour for all
>           combinations of inner and outer headers,/
>would seem better as
>/needs to/
>
>Gorry
>
>On 14/07/2010 14:43, Bob Briscoe wrote:
>>Gorry,
>>
>>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:
>>
>>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'.
>>
>>>without a change to the recommendations of the RFC itself. That is,
>>>the wording is guidance to people using tunnels and following RFC 4774.
>>>
>>>>>have a couple of procedural questions that should be considered
>>>>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:

---

From: Ben Campbell <[email-masked]>
Date: Wed, 14 Jul 2010 14:47:30 -0500

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:

> The consensus on the TSVWG list was that the updates should be identified in the RFC Index as follows
> 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.]
> 

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. 

In particular, does 3168 contain text on how it updates 2003? Could someone understand how 3168 applies to 2003 by reading that document alone? Or does that text reside in this draft?

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.

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

See my response to your separate email on this subject.

>> -- General:

[...]

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

[...]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 14 Jul 2010 14:49:28 -0500

> Looks like Gorry & I are agreeing on a way forward. Are you happy too?

Yes, it looks reasonable to me.

> And with my responses to all your other points?

I just responded to the other points in a separate email.

Thanks!

Ben.

>> I'm not too worried about the "should" in lower case, this reads fine to me the way it is.
>>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 16 Jul 2010 15:29:00 +0100

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" :-) )
>
> >> This draft is almost ready for publication 
> as a proposed standard. I have a couple of 
> procedural questions that should be considered 
> >> -- RFC Editor request (immediately after 
> ToC): "In the RFC index, RFC3168 should be identified as an update to RFC2003.
> >> This seems odd. I assume the intent is that 
> this draft says that things from 3168 should be 
> 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.
> >
>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.

> >> Should this draft be listed as updating 
> 4774? Also, you've declared this section 
> 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 
> >> -- 5.3.1, last bullet:"… the IETF Security 
> Area now considers copying acceptable given the 
> > "...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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Jul 2010 15:41:00 -0500

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:

> 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
> 
> I guess I ought to submit an erratum for RFC3168 and RFC4301 at the same time, in order to add these two "Updates" headers.
> 
> 
> 
> 
>>> 
>>> 
> 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.
> Thanks for checking all these aspects - but I'm pretty sure I had already done my due diligence in these respects.
> 
> 
> Bob
> 
> 
> 
> 
>> [...]
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 20 Jul 2010 22:07:02 +0100

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.
>
> >>>> 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?
> >>>
> >>> The consensus on the TSVWG list was that 
> the updates should be identified in the RFC Index as follows
> >> 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.
> >
> > 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
> >
> > I guess I ought to submit an erratum for 
> RFC3168 and RFC4301 at the same time, in order 
> to add these two "Updates" headers.
> >
> >
> >
> >
> >>>
> >>>
> >>> 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:
> >> It's a subtle distinction, but I'm not sure 
> the fact that 4301 says it's okay necessarily 
> > 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.
> > Thanks for checking all these aspects - but 
> I'm pretty sure I had already done my due diligence in these respects.
> >
> >
> > Bob
> >
> >
> >
> >
> >> [...]
> >