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

[Gorry Fairhurst <[e-mail]>]

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