Re: [tsvwg] Request to update draft-ietf-tsvwg-rfc6040update-shim and publish a new revision

[Bob Briscoe <[e-mail]>]

Gorry,

Sry, I didn't notice the list of comments after your signature below. 
I'll try to address these later today and submit a revised draft.
And this is to ack that I've got the new list of comments you sent too. 
Thank you again.


Bob

On 13/09/2023 10:32, Gorry Fairhurst wrote:
> Bob,
> I have been reviewing draft-ietf-tsvwg-rfc6040update-shim, to prepare 
> a publication request as the new assigned document shepherd.
>
> I think this draft is nearly ready to proceed - but it now needs a new 
> revision to update the references, and to address some concerns.
>
>
> Best wishes,
>
> Gorry Fairhurst
> (In-Coming Document Shepherd)
>
> ===
> 1. Please update all references to cite the latest rev.
> ===
> 2. Since the ID on intarea tunnels remains an item of pending work, it 
> would be wiser to explain the term outer fragments before first used - 
> citing intarea tunnels as a reference. The cited document is not the 
> easiest to parse to find this definition
>
> "Section 5.3 of [RFC3168] specifies ECN requirements for reassembly of
> sets of outer fragments."
>
> I suggest something like:
>
> Section 5.3 of [RFC3168] specifies ECN requirements for reassembly of
> sets of outer fragments [I-D.ietf-intarea-tunnels] into packets. (In 
> outer fragmentation, an outer header in each fragment indicates the 
> fragmentation and the inner transit header occurs only in the first 
> fragment, with the  following inner (transit) data broken across 
> multiple packets.)
> ===
> 3. The document provides a list that it states is confined to 
> standards track or widely deployed protocols. Some work appears to 
> have stalled/failed to progress. Please be careful not to imply a 
> projected status for this work-in-progress.
>
> "GUE (Generic UDP Encapsulation) [I-D.ietf-intarea-gue];" - This list 
> includes GUE as work-in-progress. I am unsure we can confirm 
> deployment or document status. Is it wiser to remove the ice, from the 
> list, and simply discuss this alongside Geneva in the text. I 
> understand anyway that no change is requested to this specification.
>
> ietf-nvo3-vxlan-gpe - Unsure if this ref is needed, and did not appear 
> active in the WG, and it seems no specific recommendation included?
>
> ietf-sfc-nsh-ecn-support - appears active, current text appears OK, 
> please update rev.
>
> ===
> 4. The test says:
>    The requirements in Section 4 update RFC 6040, and hence
>    implicitly update the UDP usage guidelines in RFC 8085 to add the
>    important but previously unstated requirement that, if the UDP tunnel
>    egress does not, or might not, support ECN propagation, a UDP tunnel
>    ingress has to clear the outer IP ECN field to 0b00, e.g. by
>    configuration.
> - I have thought, and I think I am OK with this choice of action, but 
> "implicitly update" is likely to attract attention from an IESG 
> review. Could we avoid "update" explicitly say something, for example 
> I suggest:
>
> NEW:
>    The requirements in Section 4 update RFC 6040, and hence
>    add to the UDP usage guidelines in RFC 8085 by addition of the
>    important, but previously unstated requirement that, if the UDP tunnel
>    egress does not, or might not, support ECN propagation, a UDP tunnel
>    ingress has to clear the outer IP ECN field to 0b00, e.g. by
>    configuration.
> ===
> 5. In 6.1.1.1., Can you define LCCE in the first sentence before the 
> quote so that the quote becomes readable?
> ADD:
> L2TP Control Connection Endpoint (LCCE)
> ===
> 6. Please could you add a VERY SHORT definition of X and E in the 
> caption of figure 1: Value Field for the LCCE Capability Attribute ...
> e.g.: (E is the ECN Capability flag, the value of X is reserved).
> ====
> 7. Please rephrase this:
> "It is believed that current implementations do not support"
> ... I'd prefer for it to say Implementation might not support, or 
> something other than the belief - when published by the IETF, the 
> RFC-Ed will not hold these beliefs, please choose another word.
> ===
> 8. Section 9 ought to be removed at this stage in the process: "9.  
> Comments Solicited"
> ====
> 9. Please confirm there is no known IPR relating to this ID, and that 
> you are content with the Editor's name being presented when published.
> ====
> 10. Please consider citing RFC 6169 as an information ref alongside 
> the first citation of RFC 4380, as a note to indicate the IETFs 
> position on current development of Teredo.
> ===
>

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