Re: [tsvwg] Chairs slides for interim meeting

["Black, David" <[e-mail]>]

Yes, the ECN Nonce is no longer relevant.  RFC 8311 (which is an IETF consensus document) states that the RFC:

   o  Declares that the ECN nonce experiment [RFC3540] has concluded and
      notes the absence of widespread deployment.

Applying errata to one or both RFCs (4774 and 8311) seems to be a suitable means of dealing with this situation.

Thanks, --David

> -----Original Message-----
> From: Rodney W. Grimes <[e-mail]>
> Sent: Wednesday, February 19, 2020 10:02 PM
> To: Rodney W. Grimes
> Cc: Black, David; [e-mail]
> Subject: Re: [tsvwg] Chairs slides for interim meeting
> 
> 
> [EXTERNAL EMAIL]
> 
> > David,
> > 	A comment in line below about your Hint to RFC 4774.
> >
> > > I've posted the chairs slides for the interim meeting on how we plan
> (hope?) to make progress in the interim meeting and at the Vancouver
> meeting.  They focus on ECT(1) usage.
> > >
> > > These slides and the rest of the materials for the interim meeting are
> (and will be) posted here: https://datatracker.ietf.org/meeting/interim-
> 2020-tsvwg-01/session/tsvwg
> > >
> > > Hint: RFC 4774 "Specifying Alternate Semantics for the Explicit Congestion
> Notification (ECN) Field" is relevant background, especially Section 4.3
> (Option 3:  Friendly Coexistence with Competing Traffic).
> >
> > In reading RFC 4774 Section 4.3 at paragraph 9 we find:
> >    A requirement for compatibility with end-nodes using default ECN is
> >    that if a packet that *could* be using default semantics is marked
> >    with the ECN codepoint "00", this marking must not be changed to
> >    "01", "10", or "11" in the network.  This prevents the packet from
> >    being represented incorrectly to a default-ECN router downstream as
> >    ECN-Capable.  Similarly, if a packet that *could* be using default
> >    semantics is marked with the ECN codepoint "01", then this codepoint
> >    should not be changed to "10" in the network (and a "10" codepoint
> >    should not be changed to "01").  This requirement is necessary to
> >    avoid interference with the transport protocol's use of the ECN nonce
> >    [RFC3540].
> >
> > For this purposes of this "Hint" can we consider that paragraph
> > to be stricken since RFC3540 and ECN nonce have been made historical
> > in scope?
> 
> Correction, last 2 sentences stricken, not the whole paragraph.
> 
> > Further I note that this RFC and BCP does not have an update to it
> > that would make the above paragraph obsolete, should something be
> > done about that?  An errata?
> >
> >
> > Thanks,
> > Rod
> >
> > > Thanks, --David (with apologies for extending the IETF practice of just-in-
> time slide preparation)
> > > ----------------------------------------------------------------
> > > David L. Black, Sr. Distinguished Engineer, Dell EMC
> > > Dell Technologies, Infrastructure Systems Group
> > > 176 South St., Hopkinton, MA  01748
> > > [phone]<tel:[phone]>           Mobile: [phone]-
> 7754<tel:[phone]>
> > > [e-mail]<mailto:[e-mail]>
> > > ----------------------------------------------------------------
> > --
> > Rod Grimes                                                 [e-mail]
> >
> >
> 
> --
> Rod Grimes                                                 [e-mail]