Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-rfc6040update-shim-21: (with COMMENT)

[Bob Briscoe <[e-mail]>]

Rob,

Thx for persevering with me. I agree with you, now that I understand 
it's about allowing non-manual approaches. I'll use your proposed text.

Bob

On 04/12/2023 13:25, Rob Wilton (rwilton) wrote:
>
> Hi Bob,
>
> Please see inline …
>
> *From:*Bob Briscoe <[e-mail]>
> *Sent:* Friday, December 1, 2023 11:31 PM
> *To:* Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]
> *Subject:* Re: [tsvwg] Robert Wilton's No Objection on 
> draft-ietf-tsvwg-rfc6040update-shim-21: (with COMMENT)
>
> Robert, Thank you for these thoughts. Pls see [BB]
>
> On 24/11/2023 13:06, Robert Wilton via Datatracker wrote:
>
>     Robert Wilton has entered the following ballot position for
>
>     draft-ietf-tsvwg-rfc6040update-shim-21: No Objection
>
>     When responding, please keep the subject line intact and reply to all
>
>     email addresses included in the To and CC lines. (Feel free to cut this
>
>     introductory paragraph, however.)
>
>     Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
>
>     for more information about how to handle DISCUSS and COMMENT positions.
>
>     The document, along with other ballot positions, can be found here:
>
>     https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>
>     ----------------------------------------------------------------------
>
>     COMMENT:
>
>     ----------------------------------------------------------------------
>
>     Hi,
>
>     Thanks for this document, I found it interesting to read.  A couple of minor
>
>     comments for you to consider:
>
>     (1) p 5, sec 4.  Making a non-ECN Tunnel Ingress Safe by Configuration
>
>            Whether or not an ingress implementation claims compliance with
>
>            RFC 6040, RFC 4301 or RFC3168, when the outer tunnel header is IP
>
>            (v4 or v6), if possible, the operator MUST configure the ingress
>
>            to zero the outer ECN field in any of the following cases:
>
>     As a minor comment, I wonder whether RFCs should be specifying requirements on
>
>     people (i.e., operators), or whether it would be better to place the
>
>     requirement on the deployment.
>
>
> [BB] We (the WG) had to work out how to navigate this particularly 
> tricky balancing act. The following paras at the end of §3 were 
> intended to explain:
>
>     However, the ECN field is a non-optional part of the IP header (v4
>     and v6). So any implementation that creates an outer IP header has
>     to give the ECN field some value. There is only one safe value a
>     tunnel ingress can use if it does not know whether the egress
>     supports propagation of the ECN field; it has to clear the ECN
>     field in any outer IP header to 0b00.
>
>     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 predated the RFC. Therefore it
>     would have been unreasonable to add such a requirement to RFC
>     6040. Nonetheless, to ensure safe propagation of the ECN field
>     over tunnels, it is reasonable to add requirements on operators,
>     to ensure they configure their tunnels safely (where possible).
>
>
> Perhaps your suggestion has taken this all into account, so you're 
> suggesting that placing the requirement on the deployment would be 
> better than on the operator (of the deployment). Perhaps, but I always 
> prefer the active to the passive. "A deployment of an ingress SHOULD 
> be configured to zero the outer," is less clear than, "The operator 
> SHOULD configure the ingress to zero the outer."
>
> */[Rob Wilton (rwilton)] /*
>
> */I was perhaps thinking of something more like: /**//*
> *//*if possible, the ingress device SHOULD be configured to
>          zero the outer ECN field in any of the following cases:
>
> *//*
>
> */This text has the benefit of applying no matter how the 
> configuration came into effect, e.g., perhaps it is being configured 
> via a controller, or even as part of a configuration template produced 
> by a controller manufacturer./*
>
> /
> /
> FWIW, I'm not sure what the problem is with placing requirements on 
> people. I've seen drafts 'corrected' when they place requirements on 
> implementers, rather than implementations. But is this practice 
> actually documented anywhere, or is there any rationale to support it? 
> I'm always willing to learn if there is.
>
> */[Rob Wilton (rwilton)] /*
>
> */Placing the requirement on the person seems to unnecessarily 
> constrain compliance to only where a person is actively involved in 
> the process.  Is that the goal here?  I.e., does the requirement still 
> apply if the action is being taken by a machine, code, or some other 
> automation?/*
>
> *//*
>
> */Ultimately, I think that it doesn’t matter who takes the action, 
> what really matters is how the protocol behaves and hence that is why 
> I believe that it is more precise to place the constraints on the 
> required resultant effect, not on the person/action to achieve that 
> effect./*
>
> *//*
>
> */But this is also a non-blocking comment.  I.e., you can keep the 
> text in the active tense if you wish, and I suspect folks will manage 
> to infer the actual underlying intent. /*
>
>     (2) p 10, sec 6.1.1.  L2TP (v2 and v3) ECN Extension
>
>         L2TP maintainers are RECOMMENDED to implement the ECN extension to
>
>         L2TPv2 and L2TPv3 defined in Section 6.1.1.2 below, in order to
>
>         provide the benefits of ECN [RFC8087], whenever a node within an L2TP
>
>         tunnel becomes the bottleneck for an end-to-end traffic flow.
>
>     Similarly to my previous comment, should the RFC 2119 requirement be placed on
>
>     the maintainers, or should it be placed on an updated versions of L2TP?
>
>
> [BB] Here, I agree with you. Proposed replacement text:
>
>
>     Implementation of the ECN extension to L2TPv2 and L2TPv3 defined in Section
>     6.1.1.2 below is RECOMMENDED, in order to provide the benefits of ECN...
>
>
> Similarly, with the identically structured requirements in the GRE and 
> AMT sections.
>
> Thank you.
>
>
> Bob
>
> */[Rob Wilton (rwilton)] /*
>
> */Regards,/*
>
> */Rob/*
>
>
>
>     Regards,
>
>     Rob
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/