Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

[Bob Briscoe <[e-mail]>]

David, An extra thought added to (d) below...

On 18/05/2019 00:27, Bob Briscoe wrote:
> David,
>
> Three push backs and a question:
> a) The MUST and SHOULD you quote below are surely not BCP, they are 
> straight protocol implementation spec.
>
> b) I believe it is important that this safety update to RFC6040 is 
> formally flagged as an update, so it gets noticed and hopefully acted 
> upon.
>
> c) Also, all the updates to specific protocols in the shim draft start 
> with a section like the following example:
>
>
>           5.1.4.1
>           <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-08#section-5.1.4.1>.
>           Safe Configuration of a 'Non-ECN' Ingress AMT Relay
>
>     The following text is appended toSection 4.2.2 of [RFC7450]  <https://tools.ietf.org/html/rfc7450#section-4.2.2>  as an
>     update to the AMT specification:
>
>        The operator of an AMT relay that does not supportRFC 6040  <https://tools.ietf.org/html/rfc6040>  or one
>        of its compatible predecessors (RFC 4301  <https://tools.ietf.org/html/rfc4301>  or the full functionality
>        mode ofRFC 3168  <https://tools.ietf.org/html/rfc3168>) MUST follow the configuration requirements in
>        Section 4  <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-08#section-4>  of RFCXXXX to ensure it clears the outer IP ECN field to
>        zero. {RFCXXXX refers to the present document so it will need to
>        be inserted by the RFC Editor}
>
> For implementers updating a particular protocol (e.g. AMT) it would be 
> gratuitously weird to have moved Section 4 into a different RFC 
> (especially one that did not have PS status).
>
> d) Do you agree with my assessment that the MUST you quote below 
> doesn't make anything non-compliant that wasn't already non-compliant 
> with 2474. And anything that wants to claim support for anything to do 
> with ECN has to comply with the aspect of 2474 that split off the last 
> 2 bits from the ToS byte?
>
> If so, there's no longer a problem to solve. Let's move on. This has 
> dragged on long enough.

[BB] Would the following text change to S.4 of the shim draft also help?

CURRENT:

    There might be concern that the above "MUST" makes compliant
    equipment non-compliant at a stroke.  However, any equipment that is
    still treating the former ToS octet (IPv4) or the former Traffic
    Class octet (IPv6) as a single 8-bit field is already non-compliant,
    and has been since 1998 when the upper 6 bits were separated off for
    the Diffserv field [RFC2474  <https://tools.ietf.org/html/rfc2474>], [RFC3260  <https://tools.ietf.org/html/rfc3260>].

SUGGESTED:

    There might be concern that the above "MUST" makes compliant
    equipment non-compliant at a stroke.  However, by definition it solely applies to
    equipment that provides Diffserv configuration. Any such Diffserv equipment that is
    configuring treatment of the former ToS octet (IPv4) or the former Traffic
    Class octet (IPv6) as a single 8-bit field must have always been non-compliant
    with the definition of the 6-bit Diffserv codepoint in [RFC2474  <https://tools.ietf.org/html/rfc2474>].




Bob

>
>
> Bob
>
> PS. Thx for other response on ecn-encap - mañana.
>
>
> On 17/05/2019 16:34, Black, David wrote:
>>
>> Before going further down the compliance rathole, let me suggest an 
>> alternative that might resolve this quickly.
>>
>> The crucial text (whose technical correctness is not in question) is:
>>
>>       In order that the network operator can comply with the above
>>
>> safety rules, even if an implementation of a tunnel ingress does
>>
>> not claim to support RFC 6040, RFC 4301 or the full functionality
>>
>> mode of RFC 3168:
>>
>>       * it MUST make propagation of the ECN field between inner and
>>
>> outer IP headers independent of any configuration of Diffserv
>>
>> codepoint propagation;
>>
>>       * it SHOULD be able to be configured to zero the outer ECN field.
>>
>> The headaches are being caused by treating that text as an update to 
>> RFC 6040, but looking at it now,
>>
>> it reads like a best current practice recommendation, so …
>>
>> Would it be reasonable to move that text into the ecn-encapsulation 
>> draft (which is intended to become
>>
>> a BCP)? Doing that would sidestep the entire discussion of 
>> consequences of the consequences of
>>
>> updating RFC 6040 with that text.
>>
>> If that sounds plausible, we should take a look at whether any of the 
>> other RFC 6040 update text in section
>>
>> 4 should likewise be moved to the ECN encapsulation draft.
>>
>> Thanks, --David
>>
>> *From:*Bob Briscoe <[e-mail]>
>> *Sent:* Thursday, May 16, 2019 7:44 PM
>> *To:* Black, David; [e-mail]
>> *Subject:* Re: [tsvwg] David Black's WGLC review of 
>> draft-ietf-tsvwg-rfc6040update-shim-08
>>
>> [EXTERNAL EMAIL]
>>
>> David,
>>
>> I'll split your email in two and solely deal with the major issue 
>> first. See inline.
>>
>> On 09/05/2019 02:08, Black, David wrote:
>>
>>     idnits found a couple of minor things:
>>
>>       * Current reference for IKEv2 is RFC 7296 instead of RFC 5996
>>       * If any text was copied from pre-5378 RFCs, an additional
>>         boilerplate disclaimer is required.
>>
>>     Thanks, --David
>>
>>     *From:* Black, David
>>     *Sent:* Wednesday, May 8, 2019 8:50 PM
>>     *To:* [e-mail] <mailto:[e-mail]>
>>     *Subject:* David Black's WGLC review of
>>     draft-ietf-tsvwg-rfc6040update-shim-08
>>
>>     This is a solidly written draft on updating tunnel protocols that
>>     use shim headers to propagate ECN according to RFC 6040.
>>
>>     Unfortunately, I found a major issue with the updates [1] along
>>     with a few minor issues (easily dealt with) and a bunch of
>>     editorial items.
>>
>>     The major issue [1] on updates creating non-compliant
>>     implementations looks like it will need WG discussion on what
>>     should be done, as the “right thing to do” appears to be in
>>     potential conflict with deployed “running code”.
>>
>>     --- Major ---
>>
>>     [1] Compliance with RFC 6040 update
>>
>>     Section 3.1 says:
>>
>>     However, an RFC has no jurisdiction over implementations that choose
>>
>>     not to comply with it or cannot comply with it, including all those
>>
>>     implementations that pre-dated the RFC.  Therefore it would have been
>>
>>     unreasonable to add such a requirement to RFC 6040.
>>
>>     But then Section 4 goes on to do exactly that by updating RFC 6040 to
>>
>>     add this text:
>>
>>     In order that the network operator can comply with the above
>>
>>     safety rules, even if an implementation of a tunnel ingress does
>>
>>     not claim to support RFC 6040, RFC 4301 or the full functionality
>>
>>     mode of RFC 3168:
>>
>>     *  it MUST make propagation of the ECN field between inner and
>>
>>     outer IP headers independent of any configuration of Diffserv
>>
>>     codepoint propagation;
>>
>>     *  it SHOULD be able to be configured to zero the outer ECN field.
>>
>>     followed by this attempt to excuse the result:
>>
>>     There might be concern that the above "MUST" makes compliant
>>
>>     equipment non-compliant at a stroke.  However, any equipment that is
>>
>>     still treating the former ToS octet (IPv4) or the former Traffic
>>
>>     Class octet (IPv6) as a single 8-bit field is already non-compliant,
>>
>>     and has been since 1998 when the upper 6 bits were separated off for
>>
>>     the Diffserv field [RFC2474], [RFC3260].  For instance, copying the
>>
>>     ECN field as a side-effect of copying the DSCP is a seriously unsafe
>>
>>     bug that risks breaking the feedback loops that regulate load on a
>>
>>     tunnel.
>>
>>     These three chunks of text need to be aligned..  I'm not sure
>>     what should
>>
>>     be done here, as the concern about updating RFC 6040 to cause
>>     non-compliance
>>
>>     is an important concern.
>>
>> [BB] This draft proposes to update RFC6040, which in turn updated 
>> RFC3168, which in turn updated RFC2474 (there were other RFCs in the 
>> tree of updates ending at RFC6040, but those updates were not with 
>> respect to the Diffserv/ECN fields).
>>
>> I fully agree that we have to be careful not to make any equipment 
>> that already complies with any of these RFCs non-compliant. And we 
>> don't...
>>
>> If any equipment does not satisfy the proposed 'MUST' statement 
>> above, it will not be treating the DSCP and the ECN fields 
>> independently. Such equipment would not have complied with RFC2474, 
>> which separated out the last 2 bits of the ToS byte, which made it 
>> possible to specify ECN in the first place.
>>
>> So the proposed 'MUST' statement does not make any equipment that 
>> complied with any of these RFCs non-compliant, unless it was already 
>> non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. 
>> So the equipment would already be non-compliant with all these RFCs.
>>
>> Now, check the detailed wording:
>>
>> even if an implementation of a tunnel ingress does
>>
>> not claim to support RFC 6040, RFC 4301 or the full functionality
>>
>> mode of RFC 3168:
>>
>> *  it MUST make propagation of the ECN field between inner and
>>
>> outer IP headers independent of any configuration of Diffserv
>>
>> codepoint propagation;
>>
>>
>> You'll notice RFC2474 is not in the list of RFCs that an 
>> implementation might even not claim to support. That's because the 
>> MUST is about Diffserv configuration. If equipment offers any 
>> Diffserv configuration, it already has to comply with RFC2474. 
>> However, if it doesn't already comply with this MUST, it already 
>> doesn't comply with RFC2474.
>>
>> So again, this MUST does not make any equipment that complied with 
>> any of the chain of RFCs non-compliant, unless they were already 
>> non-compliant with RFC2474, and therefore non-compliant with all the 
>> RFCs in the chain of updates up to RFC6040, because RFC2474 
>> grandfathered the chain.
>>
>>
>>
>>     Analogous non-compliance concerns apply to the updates to other
>>     RFCs in
>>
>>     Section 5 to varying degrees.
>>
>> If you accept my arguments above, but can still find other 
>> non-compliance concerns, please do point them out.
>>
>> Nonetheless, I'm pretty sure I've been similarly careful to avoid 
>> introducing any non-compliance surprises.
>>
>>
>>
>> Bob
>>
>>
>>
>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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