Re: [tsvwg] ECT(1): Plan for Vancouver

[Ingemar Johansson S <[e-mail]>]

Hi

I believe that the outline looks good over all .

One problem is the term "starvation". Depending on who you ask and what the
preferences are, you are likely to get different opinions.
The discussion I have seen on this list is more about that certain traffic
classes are potentially treated more unfairly for a number of reasons. But
based on how I interpret the term "starvation" I don't agree that the term
describes the concerns. Perhaps, what is needed is to define what goes under
"starvation". 

To take one analogy.. Income inequality is a growing concern in Sweden (yes
it's true also for socialist Sweden!). Still, it can't be claimed that
people are starving, people have food on the table. 

/I

> 
> During the interim meeting
(https://datatracker.ietf.org/meeting/interim-2020-
> tsvwg-01/session/tsvwg), the plan for dealing with ECT(1) in Vancouver was
> discussed based on version -02 of the chairs slides that are posted here:
> https://datatracker.ietf.org/doc/slides-interim-2020-tsvwg-01-sessa-ect1-
> chairs-slides/ .  The chairs believe that the rough consensus of the TSVWG
WG is
> to proceed as outlined on slides 5-7 of that slide deck, whose contents
are
> reproduced below.  Anyone who disagrees with this course of action should
> reply to the list with an explanation.
> 
> -- Slide 5: ECT(1): Agreeing on the Decision to be Made
> 
> 
> *         Next two slides: TSVWG Chairs attempt to state the decision
> 
>   *   Goal of this Interim Meeting: Rough consensus on decision to be made
>   *   Non?goal of this Interim Meeting: Actually make the decision
> 
> 
> *         Vancouver meeting plan (in order):
> 
>   1.  Begin with revised versions of next two slides
>   2.  L4S and SCE each present a few slides on best use of ECT(1) for the
Internet
>   3.  TSVWG Chairs set time & content guidelines, review and post in
advance (1
> week or more)
>      *   TSVWG Chairs frame and moderate Vancouver meeting discussion
>   4.  A small miracle happens, and the decision is made (we hope)
> 
> 
> 
> *         Now: Review next two slides for content
> 
> *         Do not attempt to make decision now.
> 
> -- Slide 6: DRAFT Vancouver SLIDE 1: Framing the ECT(1) Codepoint Decision
> 
> Background: RFC 4774 ?Specifying Alternate Semantics for the Explicit
> Congestion Notification (ECN) Field?
> 
>   *   RFC 4774 assumes DSCP as signal of alternate ECN semantics.
>   *   TSVWG situation: Two proposals that use ECT(1) as that signal [L4S,
SCE]
> 
> Decision: How ECT(1) signals alternate ECN semantics to network:
> 
>   1.  Input, e.g., classifier for ?queue? selection [L4S]
>   2.  Output, e.g., indication of lesser degree of ?queue? congestion
[SCE]
> At Internet scope: Choose at most one, not both.
> 
> -- Slide 7: DRAFT Vancouver SLIDE 2: Friendly Coexistence with Competing
> Traffic
> 
> Both proposals [L4S, SCE] employ RFC 4774 Option 3 (section 4.3):
> 
>   *   Incremental Deployment Option 3: Friendly Coexistence with Competing
> Traffic
>   *   Competing Traffic uses existing TCP congestion control, e.g., Reno,
Cubic,
> etc.
> Coexistence Focus: Shared bottleneck queue with ECN AQM [RFC 3168]
> 
>   *   FQ network nodes: Not a significant cause of coexistence problems
> Scenario: Traffic competition at shared bottleneck queue:
> 
>   1.  Starvation of one class of traffic is not an acceptable outcome.
>      *   Starvation may occur in network and/or at endpoints (e.g., caused
by
> congestion response)
>   2.  Competing Traffic drives bottleneck queue occupancy level.
> Proposals need to explain how to deal with this scenario.
> 
> Thanks, --David (on behalf of David, Wes & Gorry - TSVWG chairs)
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mailarchive.ietf.org/arch/browse/tsvwg/attachments/20200303/4af66
> b29/attachment.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 03 Mar 2020 16:17:11 -0800
> From: Stephen Farrell via Datatracker <[e-mail]>
> To: <[e-mail]>
> Cc: [e-mail],
> 	[e-mail], [e-mail]
> Subject: [tsvwg] Secdir last call review of
> 	draft-ietf-tsvwg-datagram-plpmtud-15
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
> 
> Reviewer: Stephen Farrell
> Review result: Has Issues
> 
> 
> Hi,
> 
> As Hilary Orman always nicely says: do not be alarmed,
> this is just a secdir review:-)
> 
> I classed this as "has issues," but the issues below should be
> fairly easy to fix.  Maybe all but 2 are real issues that say are
> worth fixing, if I'm right about 'em (but I'm also often wrong
> too:-)
> 
> Cheers,
> S.
> 
> - Abstract: This draft aims for proposed standard but is
> updating a BCP (RFC8085/BCP145).  I'm happy to leave the
> process-lawyering for that to others.
> 
> - 4.1: I'm not sure if this is recommending that PLs allow for
> padding outside of cryptographic protection. If so, that
> seems like an anti-pattern when considering the overall set of
> requirements one might envisage for a PL. If not, that's fine,
> but would it be worth stating that?
> 
> - 4.4: Would you count the AEAD tag length in the MPS of an
> AEAD-encrypting PL or not? I assume not, and the tag length
> is counted as PL overhead even if sent as a sort-of trailer
> within the ciphertext?
> 
> - 4.4: What'd be the MPS etc for an MP-TCP-like PL? Is that
> well-defined?
> 
> - 4.5: (a nit) "The validation SHOULD utilize information that
>   it is not simple for an off-path attacker to determine
> [RFC8085]." A SHOULD that's that vague seems likely prone to
> issues. Might be best to just s/SHOULD/ought/ or something
> like that.
> 
> - 6.2.3: what if TLS record layer padding is being done as
> well?  Probably just needs a mention, so people don't get
> their sums/APIs wrong.
> 
> - 6.3: I am surprised that the QUIC description here is ready
> to be an RFC before QUIC itself. I do see there are
> normative references, but the potential for a breaking change
> still exists, and seems a bit unwise. (I'd suggest, holding
> this in the WG 'till the referenced QUIC drafts are in the RFC
> editor queue, or else taking that bit out and putting it into
> a new I-D.)
> 
> - section 9: Ok this is a stretch so maybe not worth bothering
>   with but... A PL doing all this may be emitting oddly sized
> padding octets from time to time that piggy-back on
> application data. That (number of padding octets and the
> pattern with which those are emitted) seems like a medium-nice
> covert channel e.g. for exfiltrating data, not necessarily to
> the packet destination but to anyone on-path who can observe
> the signal.
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed,  4 Mar 2020 01:58:33 -0800 (PST)
> From: RFC Errata System <[e-mail]>
> To: [e-mail], [e-mail], [e-mail],
> 	[e-mail]
> Cc: [e-mail], [e-mail], [e-mail],
> 	[e-mail]
> Subject: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=UTF-8
> 
> The following errata report has been held for document update
> for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to
IP".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid4754
> 
> --------------------------------------
> Status: Held for Document Update
> Type: Editorial
> 
> Reported by: Bob Briscoe <[e-mail]>
> Date Reported: 2016-07-31
> Held by: Mirja K?hlewind (IESG)
> 
> Section: Header block
> 
> Original Text
> -------------
> Updates: 2474, 2401, 2003, 793
> 
> 
> Corrected Text
> --------------
> Updates: 2474, 2401, 2003, 2473, 793
> 
> Notes
> -----
> RFC 3168 updates RFC 2473 but does not indicate this in its header block.
> 
> Specifically, Section 9 of RFC 3168 defined processing of the ECN field
for
> Encapsulated Packets, which updated section 6.4 of RFC 2473, where the
> creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168
also
> updated the decapsulation behaviour of the ECN field in an IPv6 tunnel
header,
> which had not been specified in RFC2473.
> 
> Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to be
> tagged (in the RFC index and associated tools outputs) to indicate that it
is
> updated by RFC3168.
> 
> Note 2: Originally, the "Updates:" header of RFC3168 did not contain
"2003",
> which was added as a result of Errata ID 2660.
> 
> Note 3: The first sentence of section 9.1 in RFC3168 should also be
modified as
> follows:
> Original text:
>    The encapsulation of IP packet headers in tunnels is used in many
>    places, including IPsec and IP in IP [RFC2003].
> Corrected text:
>    The encapsulation of IP packet headers in tunnels is used in many
>    places, including IPsec and IP in IP [RFC2003, 2473].
> Comment:
>    Nowadays RFC2473 would be a normative reference, but RFC3168 pre-dated
> the categorisation of references into normative and informative.
> 
> Note 4: Section 9 of RFC3168 has since been updated by RFC6040.
Nonetheless,
> that is already correctly identified in RFC6040.
> 
> This reported errata has be moved to "Held for Document Update". While the
> reported problem is correct and needs to be addressed, it is not just an
errata
> but a larger oversight at publication time.
> 
> --------------------------------------
> RFC3168 (draft-ietf-tsvwg-ecn-04)
> --------------------------------------
> Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> Publication Date    : September 2001
> Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> Category            : PROPOSED STANDARD
> Source              : Transport Area Working Group
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 4 Mar 2020 11:06:15 +0100
> From: Mirja Kuehlewind <[e-mail]>
> To: [e-mail]
> Cc: Bob Briscoe <[e-mail]>, [e-mail],
> 	[e-mail],  IESG <[e-mail]>
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <[e-mail]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi tsvwg,
> 
> I just moved this errata to ?Held for Document Update? as there are
multiple
> points in this errata which go beyond just being an errata.
> 
> However there is also errata 4997 which only address the missing update:
> 
> https://www.rfc-editor.org/errata/eid4997
> 
> Should this errata be verified and the update tag added?
> 
> Mirja
> 
> 
> 
> > On 4. Mar 2020, at 10:58, RFC Errata System <[e-mail]>
> wrote:
> >
> > The following errata report has been held for document update
> > for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to
IP".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid4754
> >
> > --------------------------------------
> > Status: Held for Document Update
> > Type: Editorial
> >
> > Reported by: Bob Briscoe <[e-mail]>
> > Date Reported: 2016-07-31
> > Held by: Mirja K?hlewind (IESG)
> >
> > Section: Header block
> >
> > Original Text
> > -------------
> > Updates: 2474, 2401, 2003, 793
> >
> >
> > Corrected Text
> > --------------
> > Updates: 2474, 2401, 2003, 2473, 793
> >
> > Notes
> > -----
> > RFC 3168 updates RFC 2473 but does not indicate this in its header
block.
> >
> > Specifically, Section 9 of RFC 3168 defined processing of the ECN field
for
> Encapsulated Packets, which updated section 6.4 of RFC 2473, where the
> creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168
also
> updated the decapsulation behaviour of the ECN field in an IPv6 tunnel
header,
> which had not been specified in RFC2473.
> >
> > Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to
be
> tagged (in the RFC index and associated tools outputs) to indicate that it
is
> updated by RFC3168.
> >
> > Note 2: Originally, the "Updates:" header of RFC3168 did not contain
"2003",
> which was added as a result of Errata ID 2660.
> >
> > Note 3: The first sentence of section 9.1 in RFC3168 should also be
modified as
> follows:
> > Original text:
> >   The encapsulation of IP packet headers in tunnels is used in many
> >   places, including IPsec and IP in IP [RFC2003].
> > Corrected text:
> >   The encapsulation of IP packet headers in tunnels is used in many
> >   places, including IPsec and IP in IP [RFC2003, 2473].
> > Comment:
> >   Nowadays RFC2473 would be a normative reference, but RFC3168 pre-dated
> the categorisation of references into normative and informative.
> >
> > Note 4: Section 9 of RFC3168 has since been updated by RFC6040.
> Nonetheless, that is already correctly identified in RFC6040.
> >
> > This reported errata has be moved to "Held for Document Update". While
the
> reported problem is correct and needs to be addressed, it is not just an
errata
> but a larger oversight at publication time.
> >
> > --------------------------------------
> > RFC3168 (draft-ietf-tsvwg-ecn-04)
> > --------------------------------------
> > Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> > Publication Date    : September 2001
> > Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> > Category            : PROPOSED STANDARD
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> >
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 4 Mar 2020 11:12:02 +0100
> From: Mirja Kuehlewind <[e-mail]>
> To: [e-mail]
> Cc: [e-mail], [e-mail], Magnus Westerlund
> 	<[e-mail]>, [e-mail], Gorry
> 	Fairhurst <[e-mail]>, Wesley Eddy <wes@mti-
> systems.com>,
> 	Richard Scheffenegger <[e-mail]>
> Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (5966)
> Message-ID: <[e-mail]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi tsvwg,
> 
> Another errata on RFC3168.
> 
> I think this whole errata is a change that goes beyond just being an
errata,
> therefore I would suggest to mark this as ?Held for Document Update?.
> 
> I guess we could have an errata for only adding the word ?new? in section
6.1
> but that would need to be a separate errata then.
> 
> Any opinions?
> 
> Mirja
> 
> 
> 
> > On 26. Jan 2020, at 01:57, RFC Errata System <[e-mail]>
> wrote:
> >
> > The following errata report has been submitted for RFC3168,
> > "The Addition of Explicit Congestion Notification (ECN) to IP".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5966
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Richard Scheffenegger <[e-mail]>
> >
> > Section: 6.1
> >
> > Original Text
> > -------------
> > Section 6.1 states:
> >
> >      * The sender sets the CWR flag in the TCP header of the next
> >        packet sent to the receiver to acknowledge its receipt of and
> >        reaction to the ECN-Echo flag.
> >
> > section 6.1.2 clarifies:
> >
> >
> >   We ensure that the "Congestion Window Reduced" information is
> >   reliably delivered to the TCP receiver.  This comes about from the
> >   fact that if the new data packet carrying the CWR flag is dropped,
> >   then the TCP sender will have to again reduce its congestion window,
> >   and send another new data packet with the CWR flag set.  Thus, the
> >   CWR bit in the TCP header SHOULD NOT be set on retransmitted packets.
> >
> >   When the TCP data sender is ready to set the CWR bit after reducing
> >   the congestion window, it SHOULD set the CWR bit only on the first
> >   new data packet that it transmits.
> >
> > Corrected Text
> > --------------
> > Section 6.1 should say:
> >
> >
> >      * The sender sets the CWR flag in the TCP header of the next new
> >        data packet sent to the receiver to acknowledge its receipt of
and
> >        reaction to the ECN-Echo flag.
> >
> > Section 6.1.2 should clarify, that a receiver MUST process an incoming
CWR
> > on any incoming segment, and not exclude non-new-data segments.
> >
> > This clarification allows new semantics to be used by a sender-side only
> > change, and should be taken into account by all documents updating
RFC3168.
> >
> > Notes
> > -----
> > Discrepancies in the above text lead to poorly interoperating
implementations.
> In NetBSD (and derived implementationd), the "SHOULD set CWR on new data"
> was used liberal in setting CWR on the very next packet to be sent,
regardless of
> type. While at the same time the Linux implementation performed very
stingent
> tests on the receiver side, if the sender was complying with the "SHOULD"
like a
> "MUST". In request-response session with frequently changing data
direction,
> this leads to a collapse of the congestion window, as the *BSD side will
continue
> to interpret the still latched ECE flag as an indication of another RTT of
> congestion.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC3168 (draft-ietf-tsvwg-ecn-04)
> > --------------------------------------
> > Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> > Publication Date    : September 2001
> > Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> > Category            : PROPOSED STANDARD
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 4 Mar 2020 11:45:48 +0100
> From: "Richard Scheffenegger" <[e-mail]>
> To: "Mirja Kuehlewind" <[e-mail]>,	<[e-mail]>
> Cc: <[e-mail]>, <[e-mail]>, "Magnus Westerlund"
> 	<[e-mail]>, <[e-mail]>, "Gorry
> 	Fairhurst" <[e-mail]>, "Wesley Eddy" <wes@mti-
> systems.com>
> Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (5966)
> Message-ID: <32AD4D853B034B2EA08C71260781C3AC@srichardlxp2>
> Content-Type: text/plain; format=flowed; charset="UTF-8";
> 	reply-type=original
> 
> 
> I think clarification of the CWR handling should also be mentioned in
ECN++,
> since ECT setting there is allowed on every packet.
> 
> In the fbsd environment, as 3168 allows ECT only on new data packets while
> sending, it is easy to send out CWR only when ECT is also set (in the same
> check).
> 
> Simply enhancing this in ECN++ to allow setting ECT on any packet, may
> result in also sending CWR on control packets without data. And Bob made a
> compelling case, a sender needs to reliably know when a window, during
which
> congestion occured, ends (that is, sending cwr only with new data, or
> differently, setting cwr when the octete snd_max+1 is sent in the stream.
> 
> E.g. in ecn++, the below corrected text would be prudent to have.
> 
> Best regards,
>    Richard
> 
> ----- Original Message -----
> From: "Mirja Kuehlewind" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>; "Magnus Westerlund"
> <[e-mail]>; <[e-mail]>; "Gorry
> Fairhurst"
> <[e-mail]>; "Wesley Eddy" <[e-mail]>; "Richard
> Scheffenegger" <[e-mail]>
> Sent: Wednesday, March 04, 2020 11:12 AM
> Subject: Re: [Editorial Errata Reported] RFC3168 (5966)
> 
> 
> Hi tsvwg,
> 
> Another errata on RFC3168.
> 
> I think this whole errata is a change that goes beyond just being an
errata,
> therefore I would suggest to mark this as ?Held for Document Update?.
> 
> I guess we could have an errata for only adding the word ?new? in section
> 6.1 but that would need to be a separate errata then.
> 
> Any opinions?
> 
> Mirja
> 
> 
> 
> > On 26. Jan 2020, at 01:57, RFC Errata System <[e-mail]>
> > wrote:
> >
> > The following errata report has been submitted for RFC3168,
> > "The Addition of Explicit Congestion Notification (ECN) to IP".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5966
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Richard Scheffenegger <[e-mail]>
> >
> > Section: 6.1
> >
> > Original Text
> > -------------
> > Section 6.1 states:
> >
> >      * The sender sets the CWR flag in the TCP header of the next
> >        packet sent to the receiver to acknowledge its receipt of and
> >        reaction to the ECN-Echo flag.
> >
> > section 6.1.2 clarifies:
> >
> >
> >   We ensure that the "Congestion Window Reduced" information is
> >   reliably delivered to the TCP receiver.  This comes about from the
> >   fact that if the new data packet carrying the CWR flag is dropped,
> >   then the TCP sender will have to again reduce its congestion window,
> >   and send another new data packet with the CWR flag set.  Thus, the
> >   CWR bit in the TCP header SHOULD NOT be set on retransmitted packets.
> >
> >   When the TCP data sender is ready to set the CWR bit after reducing
> >   the congestion window, it SHOULD set the CWR bit only on the first
> >   new data packet that it transmits.
> >
> > Corrected Text
> > --------------
> > Section 6.1 should say:
> >
> >
> >      * The sender sets the CWR flag in the TCP header of the next new
> >        data packet sent to the receiver to acknowledge its receipt of
and
> >        reaction to the ECN-Echo flag.
> >
> > Section 6.1.2 should clarify, that a receiver MUST process an incoming
CWR
> > on any incoming segment, and not exclude non-new-data segments.
> >
> > This clarification allows new semantics to be used by a sender-side only
> > change, and should be taken into account by all documents updating
> > RFC3168.
> >
> > Notes
> > -----
> > Discrepancies in the above text lead to poorly interoperating
> > implementations. In NetBSD (and derived implementationd), the "SHOULD
set
> > CWR on new data" was used liberal in setting CWR on the very next packet
> > to be sent, regardless of type. While at the same time the Linux
> > implementation performed very stingent tests on the receiver side, if
the
> > sender was complying with the "SHOULD" like a "MUST". In
request-response
> > session with frequently changing data direction, this leads to a
collapse
> > of the congestion window, as the *BSD side will continue to interpret
the
> > still latched ECE flag as an indication of another RTT of congestion.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC3168 (draft-ietf-tsvwg-ecn-04)
> > --------------------------------------
> > Title               : The Addition of Explicit Congestion Notification
> > (ECN) to IP
> > Publication Date    : September 2001
> > Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> > Category            : PROPOSED STANDARD
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed,  4 Mar 2020 03:30:26 -0800 (PST)
> From: RFC Errata System <[e-mail]>
> To: [e-mail], [e-mail], [e-mail],
> 	[e-mail], [e-mail],
> [e-mail]
> Cc: [e-mail], [e-mail], [e-mail],
> 	[e-mail]
> Subject: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=UTF-8
> 
> The following errata report has been held for document update
> for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures for
the
> Management of the Service Name and Transport Protocol Port Number
> Registry".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid4999
> 
> --------------------------------------
> Status: Held for Document Update
> Type: Technical
> 
> Reported by: Mark Nottingham <[e-mail]>
> Date Reported: 2017-04-19
> Held by: Mirja K?hlewind (IESG)
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> 
> 
> Corrected Text
> --------------
> 
> 
> Notes
> -----
> Many port number assignments are to individuals, but the document does not
> contemplate how they should be handled when the assignee is dead or
> otherwise can't be contacted.
> 
> The most obvious procedure to follow is a transfer (8.5), but that
requires
> de-assignment (8.2), and that doesn't cover the case above.
> 
> --------------------------------------
> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> --------------------------------------
> Title               : Internet Assigned Numbers Authority (IANA)
Procedures for the
> Management of the Service Name and Transport Protocol Port Number Registry
> Publication Date    : August 2011
> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S.
Cheshire
> Category            : BEST CURRENT PRACTICE
> Source              : Transport Area Working Group
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Wed, 4 Mar 2020 06:52:15 -0800
> From: Joseph Touch <[e-mail]>
> To: RFC Errata System <[e-mail]>
> Cc: Mark Nottingham <[e-mail]>, [e-mail],
> 	[e-mail], "Dr. Joe Touch" <[e-mail]>,
> 	[e-mail], [e-mail],
> 	[e-mail], [e-mail], [e-mail]
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[e-mail]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi, all,
> 
> I disagree; Sec 8.4 allows for IANA-initiated deassignment. The
deassignment
> procedures there and in Sec 8.3 make it clear that there?s not much point
in
> focusing on cases when the assignee can?t be contacted (for whatever
reason).
> 
> Further, sec 7.9 of RFC 7605 underscores a point made throughout RFC 6335
-
> that port assignments aren?t intended to be changed. So the lack of such a
> contact isn?t really an issue except in very rare cases (for which the
exception
> processes in RFC 6335 are already sufficient).
> 
> Joe
> 
> > On Mar 4, 2020, at 3:30 AM, RFC Errata System
<[e-mail]>
> wrote:
> >
> > The following errata report has been held for document update
> > for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures for
the
> Management of the Service Name and Transport Protocol Port Number
> Registry".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid4999
> >
> > --------------------------------------
> > Status: Held for Document Update
> > Type: Technical
> >
> > Reported by: Mark Nottingham <[e-mail]>
> > Date Reported: 2017-04-19
> > Held by: Mirja K?hlewind (IESG)
> >
> > Section: GLOBAL
> >
> > Original Text
> > -------------
> >
> >
> > Corrected Text
> > --------------
> >
> >
> > Notes
> > -----
> > Many port number assignments are to individuals, but the document does
not
> > contemplate how they should be handled when the assignee is dead or
> > otherwise can't be contacted.
> >
> > The most obvious procedure to follow is a transfer (8.5), but that
requires
> > de-assignment (8.2), and that doesn't cover the case above.
> >
> > --------------------------------------
> > RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> > --------------------------------------
> > Title               : Internet Assigned Numbers Authority (IANA)
Procedures for the
> Management of the Service Name and Transport Protocol Port Number Registry
> > Publication Date    : August 2011
> > Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S.
Cheshire
> > Category            : BEST CURRENT PRACTICE
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Wed, 4 Mar 2020 16:33:06 +0100
> From: Mirja Kuehlewind <[e-mail]>
> To: Joseph Touch <[e-mail]>
> Cc: RFC Errata System <[e-mail]>, [e-mail],
> 	[e-mail], [e-mail], "Dr. Joe Touch"
> 	<[e-mail]>, Mark Nottingham <[e-mail]>, [e-mail],
> 	[e-mail]
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[e-mail]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi Joe,
> 
> I?ve put this into ?hold for document update" because I think that is a
good
> point that can be further clarified if we ever update RFC6335 and thus
this is a
> good tool to remember. This was also how this was meant to be treated when
> Mark filed the errata; originally there was a note that this should be
hold for
> update from him which I obviously removed when I made the status change.
Of
> course anything we may or may not want to change needs further discussion.
> 
> Mirja
> 
> 
> 
> > On 4. Mar 2020, at 15:52, Joseph Touch <[e-mail]> wrote:
> >
> > Hi, all,
> >
> > I disagree; Sec 8.4 allows for IANA-initiated deassignment. The
deassignment
> procedures there and in Sec 8.3 make it clear that there?s not much point
in
> focusing on cases when the assignee can?t be contacted (for whatever
reason).
> >
> > Further, sec 7.9 of RFC 7605 underscores a point made throughout RFC
6335 -
> that port assignments aren?t intended to be changed. So the lack of such a
> contact isn?t really an issue except in very rare cases (for which the
exception
> processes in RFC 6335 are already sufficient).
> >
> > Joe
> >
> >> On Mar 4, 2020, at 3:30 AM, RFC Errata System
<[e-mail]>
> wrote:
> >>
> >> The following errata report has been held for document update
> >> for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures for
the
> Management of the Service Name and Transport Protocol Port Number
> Registry".
> >>
> >> --------------------------------------
> >> You may review the report below and at:
> >> https://www.rfc-editor.org/errata/eid4999
> >>
> >> --------------------------------------
> >> Status: Held for Document Update
> >> Type: Technical
> >>
> >> Reported by: Mark Nottingham <[e-mail]>
> >> Date Reported: 2017-04-19
> >> Held by: Mirja K?hlewind (IESG)
> >>
> >> Section: GLOBAL
> >>
> >> Original Text
> >> -------------
> >>
> >>
> >> Corrected Text
> >> --------------
> >>
> >>
> >> Notes
> >> -----
> >> Many port number assignments are to individuals, but the document does
not
> >> contemplate how they should be handled when the assignee is dead or
> >> otherwise can't be contacted.
> >>
> >> The most obvious procedure to follow is a transfer (8.5), but that
requires
> >> de-assignment (8.2), and that doesn't cover the case above.
> >>
> >> --------------------------------------
> >> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> >> --------------------------------------
> >> Title               : Internet Assigned Numbers Authority (IANA)
Procedures for the
> Management of the Service Name and Transport Protocol Port Number Registry
> >> Publication Date    : August 2011
> >> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S.
Cheshire
> >> Category            : BEST CURRENT PRACTICE
> >> Source              : Transport Area Working Group
> >> Area                : Transport
> >> Stream              : IETF
> >> Verifying Party     : IESG
> >>
> >
> >
> 
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Wed, 4 Mar 2020 07:44:05 -0800
> From: Joseph Touch <[e-mail]>
> To: Mirja Kuehlewind <[e-mail]>
> Cc: Magnus Westerlund <[e-mail]>, TSVWG
> 	<[e-mail]>, "Dr. Joe Touch" <[e-mail]>, Mark Nottingham
> 	<[e-mail]>, IESG <[e-mail]>, [e-mail], RFC
> 	Errata System <[e-mail]>
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[e-mail]>
> Content-Type: text/plain;	charset=utf-8
> 
> I think there are two related but importantly distinct issues, if we want
to do
> that:
> 
> - orphans (assignee cannot be contacted, for whatever reason)
> - organizational assignee transitions (company dissolves, takeover, etc)
> 
> Both of these arguably involve legal issues that may be difficult to
navigate. If a
> port goes with the assigned company, then is it also similarly inherited
upon
> death?
> 
> The note should point out that the assignee isn?t a shepherd of the
assignment;
> changes are always supposed to be a very rare exception exactly because it
is
> nearly impossible to prove a negative (that no deployed systems are
affected by
> changes).
> 
> Joe
> 
> > On Mar 4, 2020, at 7:33 AM, Mirja Kuehlewind <[e-mail]>
wrote:
> >
> > Hi Joe,
> >
> > I?ve put this into ?hold for document update" because I think that is a
good
> point that can be further clarified if we ever update RFC6335 and thus
this is a
> good tool to remember. This was also how this was meant to be treated when
> Mark filed the errata; originally there was a note that this should be
hold for
> update from him which I obviously removed when I made the status change.
Of
> course anything we may or may not want to change needs further discussion.
> >
> > Mirja
> >
> >
> >
> >> On 4. Mar 2020, at 15:52, Joseph Touch <[e-mail]> wrote:
> >>
> >> Hi, all,
> >>
> >> I disagree; Sec 8.4 allows for IANA-initiated deassignment. The
deassignment
> procedures there and in Sec 8.3 make it clear that there?s not much point
in
> focusing on cases when the assignee can?t be contacted (for whatever
reason).
> >>
> >> Further, sec 7.9 of RFC 7605 underscores a point made throughout RFC
6335
> - that port assignments aren?t intended to be changed. So the lack of such
a
> contact isn?t really an issue except in very rare cases (for which the
exception
> processes in RFC 6335 are already sufficient).
> >>
> >> Joe
> >>
> >>> On Mar 4, 2020, at 3:30 AM, RFC Errata System
<[e-mail]>
> wrote:
> >>>
> >>> The following errata report has been held for document update
> >>> for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures
for
> the Management of the Service Name and Transport Protocol Port Number
> Registry".
> >>>
> >>> --------------------------------------
> >>> You may review the report below and at:
> >>> https://www.rfc-editor.org/errata/eid4999
> >>>
> >>> --------------------------------------
> >>> Status: Held for Document Update
> >>> Type: Technical
> >>>
> >>> Reported by: Mark Nottingham <[e-mail]>
> >>> Date Reported: 2017-04-19
> >>> Held by: Mirja K?hlewind (IESG)
> >>>
> >>> Section: GLOBAL
> >>>
> >>> Original Text
> >>> -------------
> >>>
> >>>
> >>> Corrected Text
> >>> --------------
> >>>
> >>>
> >>> Notes
> >>> -----
> >>> Many port number assignments are to individuals, but the document does
> not
> >>> contemplate how they should be handled when the assignee is dead or
> >>> otherwise can't be contacted.
> >>>
> >>> The most obvious procedure to follow is a transfer (8.5), but that
requires
> >>> de-assignment (8.2), and that doesn't cover the case above.
> >>>
> >>> --------------------------------------
> >>> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> >>> --------------------------------------
> >>> Title               : Internet Assigned Numbers Authority (IANA)
Procedures for
> the Management of the Service Name and Transport Protocol Port Number
> Registry
> >>> Publication Date    : August 2011
> >>> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund,
S. Cheshire
> >>> Category            : BEST CURRENT PRACTICE
> >>> Source              : Transport Area Working Group
> >>> Area                : Transport
> >>> Stream              : IETF
> >>> Verifying Party     : IESG
> >>>
> >>
> >>
> >
> 
> 
> 
> ------------------------------
> 
> Message: 11
> Date: Wed, 4 Mar 2020 16:55:19 +0100
> From: Mirja Kuehlewind <[e-mail]>
> To: Joseph Touch <[e-mail]>
> Cc: Magnus Westerlund <[e-mail]>, TSVWG
> 	<[e-mail]>, Mark Nottingham <[e-mail]>,
> 	[e-mail]
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[e-mail]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi Joe,
> 
> At this point I can not easily change the note anymore. I would need to
ask the
> RFC Editor to move the state back to ?Reported" but given this is not a
verified
> errata but just a reminder for a potentially document update, I?m not sure
if that
> really needed.
> 
> Mirja
> 
> 
> 
> > On 4. Mar 2020, at 16:44, Joseph Touch <[e-mail]> wrote:
> >
> > I think there are two related but importantly distinct issues, if we
want to do
> that:
> >
> > - orphans (assignee cannot be contacted, for whatever reason)
> > - organizational assignee transitions (company dissolves, takeover, etc)
> >
> > Both of these arguably involve legal issues that may be difficult to
navigate. If
> a port goes with the assigned company, then is it also similarly inherited
upon
> death?
> >
> > The note should point out that the assignee isn?t a shepherd of the
> assignment; changes are always supposed to be a very rare exception
exactly
> because it is nearly impossible to prove a negative (that no deployed
systems are
> affected by changes).
> >
> > Joe
> >
> >> On Mar 4, 2020, at 7:33 AM, Mirja Kuehlewind <[e-mail]>
wrote:
> >>
> >> Hi Joe,
> >>
> >> I?ve put this into ?hold for document update" because I think that is a
good
> point that can be further clarified if we ever update RFC6335 and thus
this is a
> good tool to remember. This was also how this was meant to be treated when
> Mark filed the errata; originally there was a note that this should be
hold for
> update from him which I obviously removed when I made the status change.
Of
> course anything we may or may not want to change needs further discussion.
> >>
> >> Mirja
> >>
> >>
> >>
> >>> On 4. Mar 2020, at 15:52, Joseph Touch <[e-mail]> wrote:
> >>>
> >>> Hi, all,
> >>>
> >>> I disagree; Sec 8.4 allows for IANA-initiated deassignment. The
> deassignment procedures there and in Sec 8.3 make it clear that there?s
not
> much point in focusing on cases when the assignee can?t be contacted (for
> whatever reason).
> >>>
> >>> Further, sec 7.9 of RFC 7605 underscores a point made throughout RFC
6335
> - that port assignments aren?t intended to be changed. So the lack of such
a
> contact isn?t really an issue except in very rare cases (for which the
exception
> processes in RFC 6335 are already sufficient).
> >>>
> >>> Joe
> >>>
> >>>> On Mar 4, 2020, at 3:30 AM, RFC Errata System <rfc-editor@rfc-
> editor.org> wrote:
> >>>>
> >>>> The following errata report has been held for document update
> >>>> for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures
for
> the Management of the Service Name and Transport Protocol Port Number
> Registry".
> >>>>
> >>>> --------------------------------------
> >>>> You may review the report below and at:
> >>>> https://www.rfc-editor.org/errata/eid4999
> >>>>
> >>>> --------------------------------------
> >>>> Status: Held for Document Update
> >>>> Type: Technical
> >>>>
> >>>> Reported by: Mark Nottingham <[e-mail]>
> >>>> Date Reported: 2017-04-19
> >>>> Held by: Mirja K?hlewind (IESG)
> >>>>
> >>>> Section: GLOBAL
> >>>>
> >>>> Original Text
> >>>> -------------
> >>>>
> >>>>
> >>>> Corrected Text
> >>>> --------------
> >>>>
> >>>>
> >>>> Notes
> >>>> -----
> >>>> Many port number assignments are to individuals, but the document
does
> not
> >>>> contemplate how they should be handled when the assignee is dead or
> >>>> otherwise can't be contacted.
> >>>>
> >>>> The most obvious procedure to follow is a transfer (8.5), but that
requires
> >>>> de-assignment (8.2), and that doesn't cover the case above.
> >>>>
> >>>> --------------------------------------
> >>>> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> >>>> --------------------------------------
> >>>> Title               : Internet Assigned Numbers Authority (IANA)
Procedures for
> the Management of the Service Name and Transport Protocol Port Number
> Registry
> >>>> Publication Date    : August 2011
> >>>> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund,
S. Cheshire
> >>>> Category            : BEST CURRENT PRACTICE
> >>>> Source              : Transport Area Working Group
> >>>> Area                : Transport
> >>>> Stream              : IETF
> >>>> Verifying Party     : IESG
> >>>>
> >>>
> >>>
> >>
> >
> >
> 
> 
> 
> ------------------------------
> 
> Message: 12
> Date: Wed, 4 Mar 2020 15:55:20 +0000
> From: Gorry Fairhurst <[e-mail]>
> To: Stephen Farrell <[e-mail]>, [e-mail]
> Cc: [e-mail],
> 	[e-mail], [e-mail]
> Subject: Re: [tsvwg] Secdir last call review of
> 	draft-ietf-tsvwg-datagram-plpmtud-15
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Thanks for this review Stephen.
> 
> On 04/03/2020 00:17, Stephen Farrell via Datatracker wrote:
> > Reviewer: Stephen Farrell
> > Review result: Has Issues
> >
> >
> > Hi,
> >
> > As Hilary Orman always nicely says: do not be alarmed,
> > this is just a secdir review:-)
> >
> > I classed this as "has issues," but the issues below should be
> > fairly easy to fix.  Maybe all but 2 are real issues that say are
> > worth fixing, if I'm right about 'em (but I'm also often wrong
> > too:-)
> >
> > Cheers,
> > S.
> >
> > - Abstract: This draft aims for proposed standard but is
> > updating a BCP (RFC8085/BCP145).  I'm happy to leave the
> > process-lawyering for that to others.
> We spoke with our TSV ADs and they? don't see any issue with this. BCP
> and Standards track are equivalent.
> > - 4.1: I'm not sure if this is recommending that PLs allow for
> > padding outside of cryptographic protection. If so, that
> > seems like an anti-pattern when considering the overall set of
> > requirements one might envisage for a PL. If not, that's fine,
> > but would it be worth stating that?
> We suggest adding to the security considerations, see later.
> > - 4.4: Would you count the AEAD tag length in the MPS of an
> > AEAD-encrypting PL or not? I assume not, and the tag length
> > is counted as PL overhead even if sent as a sort-of trailer
> > within the ciphertext?
> 
> Yes, all PL-overhead is included, but I think worth noting explicitly in
> Section 4.1 to avoid doubt. I suggest we add:
> 
> OLD:
> Protocols that permit exchange of control messages
> (without an application data block) can generate a probe packet by
> extending a control message with padding data.
> NEW:
> Protocols that permit exchange of control messages
> (without an application data block) can generate a probe packet by
> extending a control message with padding data. The total size of a
> probe packet includes all headers and padding added to the payload data
> being sent (e.g., including  protocol option fields, security-related
> fields such as an AEAD tag and TLS record layer padding).
> 
> > - 4.4: What'd be the MPS etc for an MP-TCP-like PL? Is that
> > well-defined?
> 
> For MP-TCP this isn't an issue, but each PL could have it's own issues
> and needs to work out what MPS means.
> 
> > - 4.5: (a nit) "The validation SHOULD utilize information that
> >    it is not simple for an off-path attacker to determine
> > [RFC8085]." A SHOULD that's that vague seems likely prone to
> > issues. Might be best to just s/SHOULD/ought/ or something
> > like that.
> 
> RFC8085 does provide some examples, and this is a common-enough
> transport requirement to protect from DDOS. Could the SHOULD be retained
> and this be fixed by a more specific reference perhaps?
> 
> (see Section 5.1 of [RFC8085]).
> 
> > - 6.2.3: what if TLS record layer padding is being done as
> > well?  Probably just needs a mention, so people don't get
> > their sums/APIs wrong.
> Agree. Please see proposeed text above and the proposed adds to the
> security considerations below.
> > - 6.3: I am surprised that the QUIC description here is ready
> > to be an RFC before QUIC itself. I do see there are
> > normative references, but the potential for a breaking change
> > still exists, and seems a bit unwise. (I'd suggest, holding
> > this in the WG 'till the referenced QUIC drafts are in the RFC
> > editor queue, or else taking that bit out and putting it into
> > a new I-D.)
> >
> > - section 9: Ok this is a stretch so maybe not worth bothering
> >    with but... A PL doing all this may be emitting oddly sized
> > padding octets from time to time that piggy-back on
> > application data. That (number of padding octets and the
> > pattern with which those are emitted) seems like a medium-nice
> > covert channel e.g. for exfiltrating data, not necessarily to
> > the packet destination but to anyone on-path who can observe
> > the signal.
> 
> I think this is useful. Security thoughts are always welcome. How about
> adding two extra paras to the Security Considerations, are these near?:
> 
> "DPLPMTUD methods can introduce padding data to inflate the length of
> the datagram to the total size required for a probe packet. The total
> size of a probe packet includes all headers and padding added to the
> payload data being sent (e.g., including security-related fields such as
> an AEAD tag and TLS record layer padding). The value of the padding data
> does not influence the DPLPMTUD search algorithm, and therefore needs to
> be set consistent with the policy of the PL.? A secure PL MUST provide
> cryptographic protection for the padding if this is needed to satisfy
> the security requirements of that PL.
> 
> A PL that implements this spec would send probe packets, whose size and
> frequency can be observed by the network. Designers of search algorithms
> need to consider whether the size of probe packets and the pattern of
> probing could result in a potential covert channel (e.g., for
> exfiltrating data to an on-path device or the endpoint of the connection).
"
> 
> Gorry
> 
> >
> 
> 
> 
> ------------------------------
> 
> Message: 13
> Date: Wed, 4 Mar 2020 17:42:15 +0000
> From: Bob Briscoe <[e-mail]>
> To: [e-mail]
> Cc: RFC Errata System <[e-mail]>, KK Ramakrishnan
> 	<[e-mail]>, "BLack, David" <[e-mail]>,
> [e-mail],
> 	[e-mail]
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> Mirja,
> 
> I don't even remember writing this Erratum, it's so old (or maybe it's
> me that's so old - don't comment on that tho).
> 
> The main reason for reporting omissions in the "Updates" header is to
> ensure that people who are responsible for implementations of updated
> RFCs know that they are meant to watch RFC3168 (and its updates). It
> would be useful if the tools view showed accepted errata to the Updates
> header below the "Updated by" field (in the grey area at the top of the
> HTML of a draft).
> 
> Any chance that this is possible?
> 
> 
> FYI, according to the 3168 errata list, there are 3 missing refs in the
> updates header of 3168 now. But they each have a different status:
> 
> Errata ID: 2660 <https://www.rfc-editor.org/errata/eid2660>*Status:
> Verified* Add "Updates: 2003"
> Errata ID: 4997 <https://www.rfc-editor.org/errata/eid4997> *Status:
> Reported *Add "Updates: 2460"
> Errata ID: 4754 <https://www.rfc-editor.org/errata/eid4754>*Status: Held
> for Document Update *Add "Updates: 2473"
> 
> 
> Bob
> 
> On 04/03/2020 09:58, RFC Errata System wrote:
> > The following errata report has been held for document update
> > for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to
IP".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid4754
> >
> > --------------------------------------
> > Status: Held for Document Update
> > Type: Editorial
> >
> > Reported by: Bob Briscoe <[e-mail]>
> > Date Reported: 2016-07-31
> > Held by: Mirja K?hlewind (IESG)
> >
> > Section: Header block
> >
> > Original Text
> > -------------
> > Updates: 2474, 2401, 2003, 793
> >
> >
> > Corrected Text
> > --------------
> > Updates: 2474, 2401, 2003, 2473, 793
> >
> > Notes
> > -----
> > RFC 3168 updates RFC 2473 but does not indicate this in its header
block.
> >
> > Specifically, Section 9 of RFC 3168 defined processing of the ECN field
for
> Encapsulated Packets, which updated section 6.4 of RFC 2473, where the
> creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168
also
> updated the decapsulation behaviour of the ECN field in an IPv6 tunnel
header,
> which had not been specified in RFC2473.
> >
> > Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to
be
> tagged (in the RFC index and associated tools outputs) to indicate that it
is
> updated by RFC3168.
> >
> > Note 2: Originally, the "Updates:" header of RFC3168 did not contain
"2003",
> which was added as a result of Errata ID 2660.
> >
> > Note 3: The first sentence of section 9.1 in RFC3168 should also be
modified as
> follows:
> > Original text:
> >     The encapsulation of IP packet headers in tunnels is used in many
> >     places, including IPsec and IP in IP [RFC2003].
> > Corrected text:
> >     The encapsulation of IP packet headers in tunnels is used in many
> >     places, including IPsec and IP in IP [RFC2003, 2473].
> > Comment:
> >     Nowadays RFC2473 would be a normative reference, but RFC3168 pre-
> dated the categorisation of references into normative and informative.
> >
> > Note 4: Section 9 of RFC3168 has since been updated by RFC6040.
> Nonetheless, that is already correctly identified in RFC6040.
> >
> > This reported errata has be moved to "Held for Document Update". While
the
> reported problem is correct and needs to be addressed, it is not just an
errata
> but a larger oversight at publication time.
> >
> > --------------------------------------
> > RFC3168 (draft-ietf-tsvwg-ecn-04)
> > --------------------------------------
> > Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> > Publication Date    : September 2001
> > Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> > Category            : PROPOSED STANDARD
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> 
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mailarchive.ietf.org/arch/browse/tsvwg/attachments/20200304/dd74
> 294d/attachment.html>
> 
> ------------------------------
> 
> Message: 14
> Date: Wed, 4 Mar 2020 19:37:48 +0100
> From: Mirja Kuehlewind <[e-mail]>
> To: Bob Briscoe <[e-mail]>
> Cc: "BLack, David" <[e-mail]>, TSVWG <[e-mail]>, KK
> 	Ramakrishnan <[e-mail]>
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <[e-mail]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi Bob,
> 
> I?ve sent a note about this on tsvwg list.
> 
> However, I now see that I got a bit confused about this. I thought this
errata and
> 4997 would add the same RFC in updates, which is not the case as you
correctly
> stated below.
> 
> Errata 2660 was verified a while ago and the RFC editor actually added the
> respective update tags for that RFC. So we could do the same for RFC2460
and
> RFC2473 (meaning that if ?Held for update? was not correct for this one, I
can
> request the RFC editor to revert it). However, I would like to get further
input
> from the group if that is the correct thing to do.
> 
> Mirja
> 
> 
> 
> > On 4. Mar 2020, at 18:42, Bob Briscoe <[e-mail]> wrote:
> >
> > Mirja,
> >
> > I don't even remember writing this Erratum, it's so old (or maybe it's
me that's
> so old - don't comment on that tho).
> >
> > The main reason for reporting omissions in the "Updates" header is to
ensure
> that people who are responsible for implementations of updated RFCs know
> that they are meant to watch RFC3168 (and its updates). It would be useful
if the
> tools view showed accepted errata to the Updates header below the "Updated
> by" field (in the grey area at the top of the HTML of a draft).
> >
> > Any chance that this is possible?
> >
> >
> > FYI, according to the 3168 errata list, there are 3 missing refs in the
updates
> header of 3168 now. But they each have a different status:
> >
> > Errata ID: 2660 Status: Verified Add "Updates: 2003"
> > Errata ID: 4997 Status: Reported Add "Updates: 2460"
> > Errata ID: 4754 Status: Held for Document Update Add "Updates: 2473"
> >
> >
> > Bob
> >
> > On 04/03/2020 09:58, RFC Errata System wrote:
> >> The following errata report has been held for document update
> >> for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to
IP".
> >>
> >> --------------------------------------
> >> You may review the report below and at:
> >>
> >> https://www.rfc-editor.org/errata/eid4754
> >>
> >>
> >> --------------------------------------
> >> Status: Held for Document Update
> >> Type: Editorial
> >>
> >> Reported by: Bob Briscoe
> >> <[e-mail]>
> >>
> >> Date Reported: 2016-07-31
> >> Held by: Mirja K?hlewind (IESG)
> >>
> >> Section: Header block
> >>
> >> Original Text
> >> -------------
> >> Updates: 2474, 2401, 2003, 793
> >>
> >>
> >> Corrected Text
> >> --------------
> >> Updates: 2474, 2401, 2003, 2473, 793
> >>
> >> Notes
> >> -----
> >> RFC 3168 updates RFC 2473 but does not indicate this in its header
block.
> >>
> >> Specifically, Section 9 of RFC 3168 defined processing of the ECN field
for
> Encapsulated Packets, which updated section 6.4 of RFC 2473, where the
> creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168
also
> updated the decapsulation behaviour of the ECN field in an IPv6 tunnel
header,
> which had not been specified in RFC2473.
> >>
> >> Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to
be
> tagged (in the RFC index and associated tools outputs) to indicate that it
is
> updated by RFC3168.
> >>
> >> Note 2: Originally, the "Updates:" header of RFC3168 did not contain
"2003",
> which was added as a result of Errata ID 2660.
> >>
> >> Note 3: The first sentence of section 9.1 in RFC3168 should also be
modified
> as follows:
> >> Original text:
> >>    The encapsulation of IP packet headers in tunnels is used in many
> >>    places, including IPsec and IP in IP [RFC2003].
> >> Corrected text:
> >>    The encapsulation of IP packet headers in tunnels is used in many
> >>    places, including IPsec and IP in IP [RFC2003, 2473].
> >> Comment:
> >>    Nowadays RFC2473 would be a normative reference, but RFC3168 pre-
> dated the categorisation of references into normative and informative.
> >>
> >> Note 4: Section 9 of RFC3168 has since been updated by RFC6040.
> Nonetheless, that is already correctly identified in RFC6040.
> >>
> >> This reported errata has be moved to "Held for Document Update". While
the
> reported problem is correct and needs to be addressed, it is not just an
errata
> but a larger oversight at publication time.
> >>
> >> --------------------------------------
> >> RFC3168 (draft-ietf-tsvwg-ecn-04)
> >> --------------------------------------
> >> Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> >> Publication Date    : September 2001
> >> Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> >> Category            : PROPOSED STANDARD
> >> Source              : Transport Area Working Group
> >> Area                : Transport
> >> Stream              : IETF
> >> Verifying Party     : IESG
> >>
> >
> > --
> >
> ________________________________________________________________
> > Bob Briscoe
> > http://bobbriscoe.net/
> 
> 
> 
> End of tsvwg Digest, Vol 191, Issue 3
> *************************************