Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-encap-guidelines-13.txt

From: Bob Briscoe <[email-masked]>
Date: Tue, 10 Mar 2020 17:56:59 +0000

Andy,

Just found this email. Apologies...

On 21/05/2019 15:51, Andrew G. Malis wrote:
> Bob, John, Pat,
>
> In your draft, I noticed that you reference RFC 5129 but not 5462. A 
> reference to 5462 would be useful, as it updates 5129.

My understanding is that we should cite the relevant RFC, then any 
updates to that RFC automatically apply.

I am aware of RFC5462, and I know you're only trying to be helpful, but 
I figured the /relevant/ RFC in this case was RFC5129, which defines ECN 
marking in MPLS.
Given RFC5462 is not the technical definition of ECN marking in MPLS, 
but solely gives the EXP field a new name, I don't think it's necessary 
to cite it. Particularly as there is no mention of the field name (old 
or new) in the ecn-encap draft.

Despite the length of ecn-encap, I do try to be parsimonious.

But thanks anyway for taking the care to highlight this.

Bob

>
> Cheers,
> Andy
>
>
> On Mon, May 20, 2019 at 6:40 PM <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     A New Internet-Draft is available from the on-line Internet-Drafts
>     directories.
>     This draft is a work item of the Transport Area Working Group WG
>     of the IETF.
>
>             Title           : Guidelines for Adding Congestion
>     Notification to Protocols that Encapsulate IP
>             Authors         : Bob Briscoe
>                               John Kaippallimalil
>                               Pat Thaler
>             Filename        : draft-ietf-tsvwg-ecn-encap-guidelines-13.txt
>             Pages           : 38
>             Date            : 2019-05-20
>
>     Abstract:
>        The purpose of this document is to guide the design of congestion
>        notification in any lower layer or tunnelling protocol that
>        encapsulates IP.  The aim is for explicit congestion signals to
>        propagate consistently from lower layer protocols into IP. Then the
>        IP internetwork layer can act as a portability layer to carry
>        congestion notification from non-IP-aware congested nodes up to the
>        transport layer (L4).  Following these guidelines should assure
>        interworking among IP layer and lower layer congestion notification
>        mechanisms, whether specified by the IETF or other standards
>     bodies.
>        This document updates the advice to subnetwork designers about
>     ECN in
>        RFC 3819.
>
>
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/
>
>     There are also htmlized versions available at:
>     https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-13
>     https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-13
>
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-encap-guidelines-13
>
>
>     Please note that it may take a couple of minutes from the time of
>     submission
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
>
>     _______________________________________________
>     I-D-Announce mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/i-d-announce
>     Internet-Draft directories: http://www.ietf.org/shadow.html
>     or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 10 Mar 2020 14:30:58 -0400

Bob,

Pretty funny having this suddenly pop up - I had to refresh my memory cache
for the context.

Cheers,
Andy

On Tue, Mar 10, 2020 at 1:57 PM Bob Briscoe <[email-masked]> wrote:

> My understanding is that we should cite the relevant RFC, then any updates
> to that RFC automatically apply.
>
> I am aware of RFC5462, and I know you're only trying to be helpful, but I
> figured the /relevant/ RFC in this case was RFC5129, which defines ECN
> marking in MPLS.
> Given RFC5462 is not the technical definition of ECN marking in MPLS, but
> solely gives the EXP field a new name, I don't think it's necessary to cite
> it. Particularly as there is no mention of the field name (old or new) in
> the ecn-encap draft.
>
> On Mon, May 20, 2019 at 6:40 PM <[email-masked]> wrote:
>
>>
>> This draft is a work item of the Transport Area Working Group WG of the
>> IETF.
>>
>>         Title           : Guidelines for Adding Congestion Notification
>> to Protocols that Encapsulate IP
>>         Authors         : Bob Briscoe
>>                           John Kaippallimalil
>>                           Pat Thaler
>>    mechanisms, whether specified by the IETF or other standards bodies.
>>    This document updates the advice to subnetwork designers about ECN in
>>    RFC 3819.
>>
>>
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> [email-masked]