Re: [tsvwg] [Editorial Errata Reported] RFC3168 (4754)

[Bob Briscoe <[e-mail]>]

David,


On 02/08/16 23:40, Black, David wrote:
>> As well as updating IPsec tunnelling, RFC3168 defined the ECN tunnelling
>> behaviour for IP in IP (see the start of section 9.1, as you know).
>> Given ECN field processing in IPv4 and IPv6 are identical, and both IPv4
>> and IPv6 tunnelling had been defined before RFC3168, then RFC3168 should
>> have identified that it updated both RFC2003 (IPv4) and RFC2473 (IPv6).
> Or neither ...
>
>> RFC3168 cited RFC2003, but it didn't cite RFC2473. However, clearly
>> RFC3168 did not intend to only update IPv4 tunnelling and not IPv6
>> tunnelling. That is the editorial error corrected by this erratum.
>> RFC3168 only cites 2003 once. So the erratum suggests
>>       s/[RFC2003]/[RFC2003, RFC2473]/
> ... IMHO, "update" -> "provide design guidance for" is what was intended
> at the time RFC 3168 was written, even though RFC 2119 keywords were used.
>
> In contrast, RFC 3168 contains detailed, specific IPsec updates to RFC 2401,
> and hence updated that RFC.
I think your bar for "detailed and specific" is set far too high.

As Spencer said recently, it helps if an update gives word-for-word 
update text. But an RFC doesn't have to give word-for-word editing 
commands to update another RFC. An RFC is an update if it specifies 
sufficiently detailed technical changes to another RFC.

Section 9.1 of RFC3168 gives detailed, specific and normative 
specifications of how the ECN codepoints should be handled at encap and 
decap in all IP tunnels, including IP-in-IP and IPsec.


Certainly, RFC3168 then includes section 9.2 specific to IPsec that 
re-states the above updates as word-for-word editorial updates to the 
handling of the Traffic Class field and the negotiation of attributes 
that had already been defined in RFC2401. But isn't that because RFC2401 
had already defined negotiation of handling of the Traffic Class field 
in detail, at encap and decap? Whereas RFC2003 just said the ToS field 
was copied at encap.


Extreme detail in section 9.2 (IPsec) doesn't make the detailed, 
specific and normative technical updates in section 9.1 (all IP tunnels) 
any less detailed, specific and normative. I'll leave the ADs to see if 
they think S9.1 is only guidance, but it certainly doesn't look like 
just guidance to me.  Here's a brief digest...

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Section 9.1 gives the scope as IPsec and IP in IP [RFC2003] tunnels at 
the start. And it goes on to motivate the two modes of ECN tunnelling, 
saying very clearly that either mode applies to all IP tunnels, and that 
the phrase "IP tunnel" means both IPsec and all other IP-in-IP tunnels:

    The result is that there are two viable options for the behavior of
    ECN-capable connections over an IP tunnel, including IPsec tunnels:

       * A limited-functionality option ...

       * A full-functionality option ...

It then defines the behaviour of these two options in detail, codepoint 
by codepoint, and normatively says:

       (1) An IP tunnel MUST modify the handling of the DS field octet at
       IP tunnel endpoints by implementing either the limited-
       functionality or the full-functionality option.
[...]
    All IP tunnels MUST implement the limited-functionality option, and
    SHOULD support the full-functionality option.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
That's in a Proposed Standard - it's clearly not just guidance.


Regards


Bob

>
>> FYI, an earlier erratum (Errata ID 2660) has already been verified that
>> RFC3168 should have listed 2003 in its "Updates:" header. And, as a
>> result, in the RFC index RFC2003 is now shown as updated by RFC3168.
> I probably signed off on that errata at the time.  I would not recommend
> approval if it were submitted as a new errata today.
>
> The point about consistency of treatment of whether RFC 3168 updates
> RFC 2003 and 2473 is well-taken (RFC 3168 should update both or neither).
> I'll defer to the ADs on what to do here.
>
> Thanks, --David
>
>> -----Original Message-----
>> From: Bob Briscoe [mailto:[e-mail]]
>> Sent: Monday, August 01, 2016 6:24 PM
>> To: Black, David
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: [Editorial Errata Reported] RFC3168 (4754)
>>
>> David,
>>
>>
>> On 01/08/16 14:08, Black, David wrote:
>>> Bob,
>>>
>>>> Regarding IPv6 tunnel state variables, RFC2473 says:
>>>>
>>>>       The IPv6 Tunnel Packet Traffic Class indicates the value that a
>>>>       tunnel entry-point node sets in the Traffic Class field of a tunnel
>>>>       header. The default value is zero.  The configured Packet Traffic
>>>>       Class can also indicate whether the value of the Traffic Class field
>>>>       in the tunnel header is copied from the original header, or it is set
>>>>       to the pre-configured value {default zero}.
>>>>
>>>> Once RFC3168 was written, it became inappropriate to treat the the IPv6
>>>> Traffic Class as a single 8-bit field.
>>> I'm sorry, but RFC 2474 made that change to the IPv6 traffic class field
>> definition, not RFC 3168.  The general approach taken at the time was to wait for
>> tunnel specs to be updated as opposed to retroactively changing them.
>> You are commenting on text in my email that was intended to provide
>> background for the text I put in the erratum (quoted lower down).
>> Of course you are correct that RFC2474 split the ToS octet in two, but
>> that wasn't my point. RFC2474 didn't define anything to do with
>> tunnelling (of either part). That was defined in RFC2983 and RFC3168
>> (obviously you know that because you authored both). The text in 2473 is
>> consistent with 2983 (for the 6-bit DS field), but inconsistent with
>> 3168 (for the 2-bit ECN field). That's why my proposed erratum only
>> corrects 3168, not 2983.
>>
>>> I don't think it's appropriate to add RFC 2473 as Updated by RFC 3168,
>> particularly via an Errata (Erratum?), as that was not intended at the time.  There's
>> no text in RFC 3168 indicating what it changes in RFC 2473, in contrast to the
>> lengthy discussion of IPsec tunnels.  At the very least, this is not an Editorial
>> change to RFC 3168.
>> I beg to differ.
>>
>> As well as updating IPsec tunnelling, RFC3168 defined the ECN tunnelling
>> behaviour for IP in IP (see the start of section 9.1, as you know).
>> Given ECN field processing in IPv4 and IPv6 are identical, and both IPv4
>> and IPv6 tunnelling had been defined before RFC3168, then RFC3168 should
>> have identified that it updated both RFC2003 (IPv4) and RFC2473 (IPv6).
>>
>> RFC3168 cited RFC2003, but it didn't cite RFC2473. However, clearly
>> RFC3168 did not intend to only update IPv4 tunnelling and not IPv6
>> tunnelling. That is the editorial error corrected by this erratum.
>> RFC3168 only cites 2003 once. So the erratum suggests
>>       s/[RFC2003]/[RFC2003, RFC2473]/
>>
>> FYI, an earlier erratum (Errata ID 2660) has already been verified that
>> RFC3168 should have listed 2003 in its "Updates:" header. And, as a
>> result, in the RFC index RFC2003 is now shown as updated by RFC3168.
>>
>>> I'd suggest covering RFC 2473 in your RFC 6040 update draft, and I caution that
>> having that draft update a bunch of existing RFCs to render most
>> implementations non-compliant with a new SHOULD is heavy-handed, and not
>> consistent with your request for fast processing of that draft.   It may still be the
>> proverbial "right thing to do" but it is not a straightforward simple change due to
>> the existence of "running code."
>> It was while I was updating the text of my RFC6040 update that I
>> realised that RFC2003 was approved before IPv6 [RFC2460] (previously I
>> had always assumed that RFC2003 applied to both IPv4 and IPv6). Then I
>> unearthed RFC2473 and I realised that both RFC3168 and RFC2983
>> overlooked citing 2473.
>>
>> I thought about this carefully, and realised it is not the job of my
>> RFC6040-update to update 2473, because 3168 did that update in the
>> technical sense - it just didn't do the update in the editorial sense.
>>
>> Hence the editorial erratum.
>>
>>
>> Bob
>>
>>> Thanks, --David
>>>
>>>> -----Original Message-----
>>>> From: Bob Briscoe [mailto:[e-mail]]
>>>> Sent: Sunday, July 31, 2016 12:46 PM
>>>> To: Black, David
>>>> Cc: RFC Errata System; [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail]; [e-mail]
>>>> Subject: Re: [Editorial Errata Reported] RFC3168 (4754)
>>>>
>>>> David,
>>>>
>>>> You're probably the one best placed to address this erratum, having been
>>>> one of the original authors of the tunnelling part of the ECN spec
>>>> [RFC3168], and also now being the tsvwg chair.
>>>> I happened across this problem with RFC3168 while reviewing GUE, which
>>>> uses IPv6 extension headers in the tunnel outer.
>>>>
>>>> I believe it's important to ensure "Updates:" headers are comprehensive,
>>>> because implementers don't necessarily know which RFCs they should
>>>> track, especially given IPv6 tunnel implementers wouldn't expect to have
>>>> to track transport area RFCs.
>>>>
>>>> This erratum points out that RFC2473 "Generic Packet Tunneling in IPv6
>>>> Specification" should also have been in the "Updates:" header.
>>>> Both RFC2003 and RFC 2473 were already approved when RFC3168 appeared.
>>>> (RFC2003 was written pre-IPv6 [RFC2460], whereas RFC2473 covered IPv6
>>>> tunnelling.)
>>>>
>>>> Regarding IPv6 tunnel state variables, RFC2473 says:
>>>>
>>>>       The IPv6 Tunnel Packet Traffic Class indicates the value that a
>>>>       tunnel entry-point node sets in the Traffic Class field of a tunnel
>>>>       header. The default value is zero.  The configured Packet Traffic
>>>>       Class can also indicate whether the value of the Traffic Class field
>>>>       in the tunnel header is copied from the original header, or it is set
>>>>       to the pre-configured value {default zero}.
>>>>
>>>> Once RFC3168 was written, it became inappropriate to treat the the IPv6
>>>> Traffic Class as a single 8-bit field.
>>>> I believe the above text is compatible with RFC2983 for the 6-bit
>>>> Diffserv Field, but it is not compatible with RFC3168 (or its subsequent
>>>> updates) for the 2-bit ECN field.
>>>>
>>>>
>>>> Bob
>>>>
>>>> On 31/07/16 15:03, RFC Errata System wrote:
>>>>> The following errata report has been submitted for RFC3168,
>>>>> "The Addition of Explicit Congestion Notification (ECN) to IP".
>>>>>
>>>>> --------------------------------------
>>>>> You may review the report below and at:
>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=4754
>>>>>
>>>>> --------------------------------------
>>>>> Type: Editorial
>>>>> Reported by: Bob Briscoe <[e-mail]>
>>>>>
>>>>> Section: Header block
>>>>>
>>>>> Original Text
>>>>> -------------
>>>>> Updates: 2474, 2401, 2003, 793
>>>>>
>>>>>
>>>>> Corrected Text
>>>>> --------------
>>>>> Updates: 2474, 2401, 2003, 2473, 793
>>>>>
>>>>> Notes
>>>>> -----
>>>>> RFC 3168 updates RFC 2473 but does not indicate this in its header block.
>>>>>
>>>>> Specifically, Section 9 of RFC 3168 defined processing of the ECN field for
>>>> Encapsulated Packets, which updated section 6.4 of RFC 2473, where the
>> creation
>>>> of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168 also updated
>> the
>>>> decapsulation behaviour of the ECN field in an IPv6 tunnel header, which had
>> not
>>>> been specified in RFC2473.
>>>>> Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to be
>>>> tagged (in the RFC index and associated tools outputs) to indicate that it is
>>>> updated by RFC3168.
>>>>> Note 2: Originally, the "Updates:" header of RFC3168 did not contain "2003",
>>>> which was added as a result of Errata ID 2660.
>>>>> Note 3: The first sentence of section 9.1 in RFC3168 should also be modified
>> as
>>>> follows:
>>>>> Original text:
>>>>>       The encapsulation of IP packet headers in tunnels is used in many
>>>>>       places, including IPsec and IP in IP [RFC2003].
>>>>> Corrected text:
>>>>>       The encapsulation of IP packet headers in tunnels is used in many
>>>>>       places, including IPsec and IP in IP [RFC2003, 2473].
>>>>> Comment:
>>>>>       Nowadays RFC2473 would be a normative reference, but RFC3168 pre-
>> dated
>>>> the categorisation of references into normative and informative.
>>>>> Note 4: Section 9 of RFC3168 has since been updated by RFC6040.
>> Nonetheless,
>>>> that is already correctly identified in RFC6040.
>>>>> Instructions:
>>>>> -------------
>>>>> This erratum is currently posted as "Reported". If necessary, please
>>>>> use "Reply All" to discuss whether it should be verified or
>>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>>> can log in to change the status and edit the report, if necessary.
>>>>>
>>>>> --------------------------------------
>>>>> RFC3168 (draft-ietf-tsvwg-ecn-04)
>>>>> --------------------------------------
>>>>> Title               : The Addition of Explicit Congestion Notification (ECN) to IP
>>>>> Publication Date    : September 2001
>>>>> Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
>>>>> Category            : PROPOSED STANDARD
>>>>> Source              : Transport Area Working Group
>>>>> Area                : Transport
>>>>> Stream              : IETF
>>>>> Verifying Party     : IESG
>>>>>
>>>> --
>>>>
>> ______________________________________________________________
>>>> __
>>>> Bob Briscoe                               http://bobbriscoe.net/
>> --
>> ______________________________________________________________
>> __
>> Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/