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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Thu, 05 March 2020 09:43 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC64B3A1133 for <tsvwg@ietfa.amsl.com>; Thu, 5 Mar 2020 01:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY_gJZqzVGPS for <tsvwg@ietfa.amsl.com>; Thu, 5 Mar 2020 01:42:56 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130074.outbound.protection.outlook.com [40.107.13.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686A03A1130 for <tsvwg@ietf.org>; Thu, 5 Mar 2020 01:42:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DjU7b4fCqxUxGHYeS94YKXy2OksasuCUeNC1fVYgDfjFTDOdNrzjF9fqQeCWjG?= =?utf-8?q?QncjsJjugg3r76V7Ww/lyGaWHWFke07uSZ6L+YCk7XnACCyuQmFXQvZ/eIJKMXKsz?= =?utf-8?q?WAtGubFJAnF4YIP1VlH22wQr9kBxkgeE86RV5tKEFOdREL2WvTxotlkKEUufVHPQR?= =?utf-8?q?+3P18tPG+A6an4EiILAFcTHxNUU0x+sViAYiwqHXnNH3xVCfpkBhanBotfoKmSLW0?= =?utf-8?q?TBId0Z+8VKogoUqr6cWOcgancKP1F0G/IzHqrOQdwTIhwc6DI0gKV6DlQVwPPUJTB?= =?utf-8?q?i6BiRhBjqcEIx6Thnnzhw=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3D9LASy/YjLICagrMypn73bKLm1d5TF8l9JS8t5pWpw9A=3D=3B_b=3DKIx/ys?= =?utf-8?q?unLBwb0moM4JKbkbA9Zz92H6DPoq+FNSGh3jtTFPk+IdiXOPFom85YunqGC0aTlv9?= =?utf-8?q?HI9047HfXMPEpQsmglPVgyH/UY7quN3U9wlLs9Dgk7aKD7JwuExyyFHYIQOfcDF7a?= =?utf-8?q?ziuGRf3nYku7Q5d76pwPzWbQLqCCdsusbYBCL743pqVC717wA+dARM7AYuQ9YSrYX?= =?utf-8?q?Q4Rj7PhbqLMR0KLtMjbokTMEXN1Tt0BJBxFD7R6mtWUVSfM1qwvwhHbsN5TehnxZc?= =?utf-8?q?uMPc52FFwH9OtCEQ78QFIf6iUNxzA9Pl/tx2yFfHoGa9OEbbUJcH+oL6csdVS6Krg?= =?utf-8?q?TwEWA0ZtdOw=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3AContent-Typ?= =?utf-8?q?e=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3D9LASy/YjLICagrMypn73bKLm1d5TF8l9JS8t5pWpw9A=3D=3B_b=3Dp+9NxM?= =?utf-8?q?MH03x7PqeeJu7fMz5aSxjZoDjBUIF2idnQSMsmgGeaiO2OCIiifLiSj+eFwW77LJI?= =?utf-8?q?IkMKBeZh/auYhxDgS7l6ZUg9IoA9eaV+kubk5/3VKlNHk3i0Qac/vrXhRf/Lga09G?= =?utf-8?q?WIGRaNqvsDXY+ehDKKCmYTM8gIuMAxC/ZV4=3D?=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB3130.eurprd07.prod.outlook.com (10.170.247.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11; Thu, 5 Mar 2020 09:42:51 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::e80a:dc35:1cef:7cb9]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::e80a:dc35:1cef:7cb9%7]) with mapi id 15.20.2814.007; Thu, 5 Mar 2020 09:42:51 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>, "David.Black@dell.com" <David.Black@dell.com>
CC: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: ECT(1): Plan for Vancouver
Thread-Index: AdXy0aW8fUfs7avFS4+585uxIDLF2Q==
Date: Thu, 5 Mar 2020 09:42:51 +0000
Message-ID: =?utf-8?q?=3CHE1PR07MB4425E322A17CBBCF7B601518C2E20=40HE1PR07MB4?= =?utf-8?q?425=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [192.176.1.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8e27a995-77f3-416e-37ae-08d7c0e992b1
x-ms-traffictypediagnostic: HE1PR07MB3130:|HE1PR07MB3130:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: =?utf-8?q?=3CHE1PR07MB3130A456EFDF21228EFAB8E9C2E?= =?utf-8?q?20=40HE1PR07MB3130=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-forefront-prvs: 03333C607F
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNzYwMDIpKDM5ODYwNDAwMDAyKSgzNDYwMDIpKDM5NjAwMykoMTM2?= =?utf-8?b?MDAzKSgzNjYwMDQpKDE4OTAwMykoMTk5MDA0KSg2Njk0NjAwNykoNjY2MTYwMDkp?= =?utf-8?b?KDY0NzU2MDA4KSg2NjQ0NjAwOCkoNzYxMTYwMDYpKDI2MDA1KSg2NjQ3NjAwNyko?= =?utf-8?q?66556008=29=2833656002=29=2830864003=29=2853546011=29=2881156014?= =?utf-8?b?KSg4OTM2MDAyKSgxMDc4ODYwMDMpKDE4NjAwMykoNTY2MDMwMDAwMikoNDMy?= =?utf-8?b?NjAwOCkoNDc4NjAwMDAxKSg4Njc2MDAyKSg4MTE2NjAwNikoNjUwNjAwNyko?= =?utf-8?q?7696005=29=2852536014=29=2871200400001=29=289686003=29=2886362001?= =?utf-8?b?KSgyOTA2MDAyKSg2NjU3NDAxMikoMzE2MDAyKSgxMTAxMzYwMDUpKDU1MDE2?= =?utf-8?b?MDAyKSg0NzQzMDAyKSg5NjYwMDUpKDU1OTAwMSkoNTc5MDA0KTs=?= DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3130; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?iFq0XFnG0sjv1HLVgT9TQ1K+AxVyJlu?= =?utf-8?q?8GCDQFjZohsh4DSzlOSCJqqH+cYul2RtnU/+wUqVZHY+Ur/w25jTyJnLm7kN9gn0O?= =?utf-8?q?AI4zUkox8q3H5Gnl/4IH5iioNMnuFYBznVRBLnUTjCMXmW/z87ggiQxfr3S8vE4P5?= =?utf-8?q?5r07xbDwa8k0ZPNjKY5lTtEsyThboBzWACLjIrGnLC6am3EZy5lU1Unsj1YZLNplE?= =?utf-8?q?PiJXbETCw//RcxCtQtenXrZdt6AraZJyvoekZ6M6eaj9eGuzcrXi4SqPuFboAMOFR?= =?utf-8?q?jJPPT0PfwO2BZT+7rqAz7NrMIf0aa6AEusAvh3jAnwl7lsGGlqVpVEgdQiipE1yCR?= =?utf-8?q?URgDLbGyNFN7nPySkWCkXzFmnknRfdivc3vxqMPSz8vjnv6CJzXsutubu7FA9O5xZ?= =?utf-8?q?8SnJx++P1p3iIvzy+0f483YVqkW9xNoml8hN7y9mbdHF5MV4UCRrzHmRJeWWD+lqQ?= =?utf-8?q?AwNuLLC12Oy5cq32Kt6PwRJCptMpiGQ6fcXj5Tcs8aWNpsgg=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?2cdgEBwKRrCFc5QHsR+VmumQW047i3?= =?utf-8?q?u4eITNL46lNuyrL+Qq1FUThng00pexvJWuCTxEN933nN1GGEYlDmVwk7fNWYRHEN7?= =?utf-8?q?zD7r9+0Br616/0wtSG1B+3Ydzdfv6LPzwyxt6wVXhYLcD9B38onF/+A=3D=3D?=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_009A_01D5F2DA.D0D3EE40"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e27a995-77f3-416e-37ae-08d7c0e992b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 09:42:51.5476 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?qCoMRB+kcaXYGiFwX3qwR?= =?utf-8?q?7nBSY/+PKAJclaAlh0HqHvyNzZN/dqZTi268ALdoBfy22aknUZo+PU6zc3xSL08fl?= =?utf-8?q?Js81yoq1euRZaceQOQzgw5F5TKyV+T2nxCHuv03HB0?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3130
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/e7Oruk_qtjQPX31YLBQb68z4hTs>
Subject: Re: [tsvwg] ECT(1): Plan for Vancouver
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2020 09:43:02 -0000

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 <noreply@ietf.org>
> To: <secdir@ietf.org>
> Cc: draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org,
> 	last-call@ietf.org, tsvwg@ietf.org
> Subject: [tsvwg] Secdir last call review of
> 	draft-ietf-tsvwg-datagram-plpmtud-15
> Message-ID: <158328103137.7648.9240148667630328703@ietfa.amsl.com>
> 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 <rfc-editor@rfc-editor.org>
> To: ietf@bobbriscoe.net, kk@teraoptic.com, floyd@aciri.org,
> 	black_david@emc.com
> Cc: ietf@kuehlewind.net, iesg@ietf.org, tsvwg@ietf.org,
> 	rfc-editor@rfc-editor.org
> Subject: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <20200304095833.277C3F4071F@rfc-editor.org>
> 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 <ietf@bobbriscoe.net>
> 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 <ietf@kuehlewind.net>
> To: tsvwg@ietf.org
> Cc: Bob Briscoe <ietf@bobbriscoe.net>et>, kk@teraoptic.com,
> 	black_david@emc.com,  IESG <iesg@ietf.org>
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <10D606C7-7291-422A-B2A3-1A4B4FA17332@kuehlewind.net>
> 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 <rfc-editor@rfc-editor.org>
> 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 <ietf@bobbriscoe.net>
> > 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 <ietf@kuehlewind.net>
> To: tsvwg@ietf.org
> Cc: kk@teraoptic.com, black_david@emc.com, Magnus Westerlund
> 	<magnus.westerlund@ericsson.com>om>, david.black@dell.com, Gorry
> 	Fairhurst <gorry@erg.abdn.ac.uk>uk>, Wesley Eddy <wes@mti-
> systems.com>,
> 	Richard Scheffenegger <rscheff@gmx.at>
> Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (5966)
> Message-ID: <414A38D3-915C-4C82-AAD6-FDEB1B2929E9@kuehlewind.net>
> 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 <rfc-editor@rfc-editor.org>
> 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 <rscheff@gmx.at>
> >
> > 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" <rscheff@gmx.at>
> To: "Mirja Kuehlewind" <ietf@kuehlewind.net>et>,	<tsvwg@ietf.org>
> Cc: <kk@teraoptic.com>om>, <black_david@emc.com>om>, "Magnus Westerlund"
> 	<magnus.westerlund@ericsson.com>om>, <david.black@dell.com>om>, "Gorry
> 	Fairhurst" <gorry@erg.abdn.ac.uk>uk>, "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" <ietf@kuehlewind.net>
> To: <tsvwg@ietf.org>
> Cc: <kk@teraoptic.com>om>; <black_david@emc.com>om>; "Magnus Westerlund"
> <magnus.westerlund@ericsson.com>om>; <david.black@dell.com>om>; "Gorry
> Fairhurst"
> <gorry@erg.abdn.ac.uk>uk>; "Wesley Eddy" <wes@mti-systems.com>om>; "Richard
> Scheffenegger" <rscheff@gmx.at>
> 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 <rfc-editor@rfc-editor.org>
> > 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 <rscheff@gmx.at>
> >
> > 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 <rfc-editor@rfc-editor.org>
> To: mnot@mnot.net, michelle.cotton@icann.org, lars.eggert@nokia.com,
> 	touch@isi.edu, magnus.westerlund@ericsson.com,
> cheshire@apple.com
> Cc: ietf@kuehlewind.net, iesg@ietf.org, tsvwg@ietf.org,
> 	rfc-editor@rfc-editor.org
> Subject: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <20200304113026.A855CF40725@rfc-editor.org>
> 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 <mnot@mnot.net>
> 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 <touch@strayalpha.com>
> To: RFC Errata System <rfc-editor@rfc-editor.org>
> Cc: Mark Nottingham <mnot@mnot.net>et>, michelle.cotton@icann.org,
> 	lars.eggert@nokia.com, "Dr. Joe Touch" <touch@isi.edu>du>,
> 	magnus.westerlund@ericsson.com, cheshire@apple.com,
> 	ietf@kuehlewind.net, iesg@ietf.org, tsvwg@ietf.org
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <9FDCD0E5-730B-4B19-83A5-C2A710344AD8@strayalpha.com>
> 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
<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 <mnot@mnot.net>
> > 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 <ietf@kuehlewind.net>
> To: Joseph Touch <touch@strayalpha.com>
> Cc: RFC Errata System <rfc-editor@rfc-editor.org>rg>, cheshire@apple.com,
> 	magnus.westerlund@ericsson.com, tsvwg@ietf.org, "Dr. Joe Touch"
> 	<touch@isi.edu>du>, Mark Nottingham <mnot@mnot.net>et>, iesg@ietf.org,
> 	lars.eggert@nokia.com
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <AF545F5E-278E-4D4D-BB17-5239496050CC@kuehlewind.net>
> 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 <touch@strayalpha.com> 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 <mnot@mnot.net>
> >> 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 <touch@strayalpha.com>
> To: Mirja Kuehlewind <ietf@kuehlewind.net>
> Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>om>, TSVWG
> 	<tsvwg@ietf.org>rg>, "Dr. Joe Touch" <touch@isi.edu>du>, Mark Nottingham
> 	<mnot@mnot.net>et>, IESG <iesg@ietf.org>rg>, lars.eggert@nokia.com, RFC
> 	Errata System <rfc-editor@rfc-editor.org>
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <DFD91525-CEA7-46DE-BEC9-06D6A0E61B0B@strayalpha.com>
> 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 <ietf@kuehlewind.net>
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 <touch@strayalpha.com> 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 <mnot@mnot.net>
> >>> 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 <ietf@kuehlewind.net>
> To: Joseph Touch <touch@strayalpha.com>
> Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>om>, TSVWG
> 	<tsvwg@ietf.org>rg>, Mark Nottingham <mnot@mnot.net>et>,
> 	lars.eggert@nokia.com
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <472C45E3-CC3B-4D97-AB30-050EEB5B97F3@kuehlewind.net>
> 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 <touch@strayalpha.com> 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 <ietf@kuehlewind.net>
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 <touch@strayalpha.com> 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 <mnot@mnot.net>
> >>>> 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 <gorry@erg.abdn.ac.uk>
> To: Stephen Farrell <stephen.farrell@cs.tcd.ie>ie>, secdir@ietf.org
> Cc: draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org,
> 	last-call@ietf.org, tsvwg@ietf.org
> Subject: Re: [tsvwg] Secdir last call review of
> 	draft-ietf-tsvwg-datagram-plpmtud-15
> Message-ID: <b721e053-e8f7-07d0-42c5-11fd25d5d6ea@erg.abdn.ac.uk>
> 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 <ietf@bobbriscoe.net>
> To: ietf@kuehlewind.net
> Cc: RFC Errata System <rfc-editor@rfc-editor.org>rg>, KK Ramakrishnan
> 	<kk@cs.ucr.edu>du>, "BLack, David" <David.Black@dell.com>om>,
> iesg@ietf.org,
> 	tsvwg@ietf.org
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <fafeafaf-421b-ac68-d5e6-a61a9f7c3262@bobbriscoe.net>
> 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 <ietf@bobbriscoe.net>
> > 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 <ietf@kuehlewind.net>
> To: Bob Briscoe <ietf@bobbriscoe.net>
> Cc: "BLack, David" <David.Black@dell.com>om>, TSVWG <tsvwg@ietf.org>rg>, KK
> 	Ramakrishnan <kk@cs.ucr.edu>
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <003EC68D-9136-46A2-9044-85CCBE75FDFE@kuehlewind.net>
> 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 <ietf@bobbriscoe.net> 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
> >> <ietf@bobbriscoe.net>
> >>
> >> 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
> *************************************