Re: [tsvwg] Reviewing draft-ietf-tsvwg-rfc6040update-shim

[Bob Briscoe <[e-mail]>]

Gorry,

Posted, and I added your name to the Acks for your helpful review.
Thank you.

Bob

On 22/09/2023 09:02, Gorry Fairhurst wrote:
> Bob,
>
> Many thanks for carefully working through this review list. I see you 
> have done the correct thing, and I agree with updating the text 
> relating to code points to avoid staying equivalence.
>
> I will add the list of paused INTAREA documents to our review request 
> for INT, and follow this up with an INT AD. I am sure they will 
> comment if they do see a particular direction that  is preferable for 
> how to cite these in our guidance.
>
> Please submit a revised ID.
>
> Gorry
>
>> On 21 Sep 2023, at 18:34, Bob Briscoe 
>> <ietf=[e-mail]> wrote:
>>
>>  Gorry,
>>
>> Thank you for your review comments. I've amalgamated both your lists 
>> into one email below. I've adopted all the changes you propose 
>> verbatim except where noted with "[BB]".
>>
>> I would also like to propose to make the following change:
>> Sorry, for the last-minute proposal post-WGLC, but the world has 
>> change in the x years that have passed while waiting for the 
>> dependent reference to move forward. In particular, RFC8311 ended the 
>> equivalence of ECT(0) and ECT(1).
>>
>> Reasoning should be self-explanatory - TLDR; removes unnecessary 
>> uncertainty.
>>
>> BEFORE:
>>    *  If there is mix of ECT(0) and ECT(1) fragments, then the
>>       reassembled packet MUST be set toeither ECT(0) or ECT(1). In
>>       this case, reassembly SHOULD take into account that the RFC series
>>       has so far ensured that ECT(0) and ECT(1) can either be considered
>>       equivalent, or they can provide 2 levels of congestion severity,
>>       where the ranking of severity from highest to lowest is CE,
>>       ECT(1), ECT(0) [RFC6040].
>>
>> PROPOSED:
>>    *  If there is mix of ECT(0) and ECT(1) outer fragments, then the
>>       reassembled packet MUST be set to ECT(1).
>>
>> ***Reasoning: Originally [RFC3168] defined ECT(0) and ECT(1) as
>>       equivalent, but RFC 3168 has been updated by [RFC8311] to make
>>       ECT(1) available for congestion marking differences. ***The 
>> rule is
>>       independent of***the current use of ECT(1) for L4S [RFC9331]. The**
>>       rule is compatible with PCN [RFC6660], which uses ***2 levels of
>>       congestion severity, with the ranking of severity from highest to
>>       lowest being CE, ECT(1), ECT(0))*. **The decapsulation rules in
>>       [RFC6040] take a similar approach.*
>>
>> See [BB] below...
>>
>> On 15/09/2023 07:51, Gorry Fairhurst wrote:
>>> Bob,
>>>
>>> I have been reviewing draft-ietf-tsvwg-rfc6040update-shim, to 
>>> prepare a publication request as the new assigned document shepherd. 
>>> Thanks for the new revision updating the references to cite the 
>>> latest rev.
>>>
>>> I think this draft is nearly ready to proceed - but I have review 
>>> comments that I think needs a new revision.
>>>
>>> Best wishem
>>>
>>> Gorry Fairhurst
>>> (as Document Shepherd)
>>>
>>> ===
>>> 1. 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.)
>>> ===
>>> 2.
>>> In Section 6.1.1.1., can you define LCCE in the first sentence 
>>> before the quote so that the quote becomes readable?
>>> OLD:
>>> In particular, for an LCCE
>>> NEW:
>>> In particular, L2TP Control Connection Endpoint (LCCE)
>>> ===
>>> 3.
>>> 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).
>>> ====
>>> 4. Please rephrase this:
>>> "It is believed that current implementations do not support"
>>> ... I'd suggest it does not say something about the belief - when 
>>> published by the IETF, the RFC-Ed will not hold these beliefs, 
>>> please choose another word.
>>> OLD:
>>> It is believed that
>>> NEW:
>>> At the time of publication, it is thought that
>>
>> [BB] I've used "Those implementations known to the authors at the 
>> time of writing"
>>
>>> ===
>>> 5.
>>> Section 9 ought to be removed at this stage in the process: "9. 
>>> Comments Solicited"
>>
>> [BB] I've tagged it with the XML attribute removeInRFC="true" for the 
>> RFC Editor
>> And I've moved it to after the refs, along with the Acks, which I now 
>> understand is preferred RFC style.
>>
>>> ====
>>> 6. Please consider citing RFC 6169 as an informativen ref alongside 
>>> the first citation of RFC 4380, as a note to indicate the IETFs 
>>> position on current development of Teredo.
>>
>> [BB] I'd rather not cite RFC6169 because there is nothing in it that 
>> is at all relevant to the present draft. Despite the title "Security 
>> Concerns with IP Tunneling", it only covers security concerns to do 
>> with routing and addressing, which has nothing to do with ECN 
>> propagation.
>>
>> See [BB] in your initial list below, with duplicates snipped
>> Continued...
>>
>>
>> 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.
>>
>> [BB] As you saw, now done in draft 17 (between your two emails).
>>
>>> ===
>> [snip 2]
>>
>>> 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?
>>
>> [BB] I thought it best to leave these in so that intarea review could 
>> say whether it wants any removed.
>>
>>>
>>> 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.
>>> ===
>>
>> [BB] I had independently updated this section myself and posted draft 
>> 17 the day after your first email (even though I missed the list it 
>> contained). And I notice you had removed this item from the list you 
>> sent the next day, so I assume that implied agreement.
>>
>> [snip 5-9]
>>
>>> 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.
>>> ====
>>
>> [BB] Confirmed. I know of no related IPR. And happy for my name being 
>> on it.
>>
>> [snip 10]
>>
>>
>> Bob
>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/

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