Re: [tsvwg] Comments on draft-ietf-tsvwg-ecn-encap-guidelines-13

"Black, David" <David.Black@dell.com> Tue, 10 March 2020 20:15 UTC

Return-Path: <David.Black@dell.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 D6EB53A0A38 for <tsvwg@ietfa.amsl.com>; Tue, 10 Mar 2020 13:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level:
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=b1LdGnP5; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=N8VJQTJH
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 eCloKvhyoZby for <tsvwg@ietfa.amsl.com>; Tue, 10 Mar 2020 13:15:50 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 474B13A0A2B for <tsvwg@ietf.org>; Tue, 10 Mar 2020 13:15:50 -0700 (PDT)
Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02AKCFnE008489; Tue, 10 Mar 2020 16:14:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=IZKCgUErBBXwi02d5uUy90QvL/B1lACkM5kxsCj2p2Y=; b=b1LdGnP5tkF9x3SbY0ufz/9r/wgw7wCgdPRH8ypnk5IZTfN3b7lyNfsR2zd5m68qMNaI xjNuKE1ZXJq+dMEERcdBtgOmy+Udqex/nNX20ISTJ0AZ+FyEcOqJAxJQAIXbxfqP0m6X kw8fl1wl24X/l8jAeamC2EHKKelT0wVVrb9lU2BG88vY4S/swLllGGXIPCqKRq3fR8No t86cDgL8WFWNPyLNi3RnMtCa117dK60zmxErTRnx751AM8RaJNHZZ/kad8lL0PQiZIZL yhbYCp++rIL+cbAen4vFNDQRs75RUoJcFJEdjfX5gEc22IQ/UAMeNLOJi4340Hmy6Qe/ HA==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2ym8gtm3qh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 16:14:56 -0400
Received: from pps.filterd (m0144102.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02AKA68c152901; Tue, 10 Mar 2020 16:14:55 -0400
Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-00154901.pphosted.com with ESMTP id 2ym6s4s2kh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Mar 2020 16:14:55 -0400
Received: from m0144102.ppops.net (m0144102.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 02AKDiuw159860; Tue, 10 Mar 2020 16:14:54 -0400
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2108.outbound.protection.outlook.com [104.47.70.108]) by mx0b-00154901.pphosted.com with ESMTP id 2ym6s4s2k8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Mar 2020 16:14:54 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3Df+wRhNfrz2aEIYOecwNG3nbe/7356yWbJT7PfjvRCPYybSfC+IgN5JdlseXMQ?= =?utf-8?q?VPaUnTVt+sq0YOLZpF8WIk3UxeCwA16ZNgzITmL9mA3eYxTaFzq9e8h5yDRh0nrmw?= =?utf-8?q?vNVdCipTICMz9NruxCwQcZUIzN6rwZzbnI9aKHp556vASF4OYHfNocbRv6r4qTREg?= =?utf-8?q?DE1MjxdIYQPtk3eKOd/INWpcW51xrCHu0/Zx7PbCZj93RI5w6QXu0ryjyD/6LbrHz?= =?utf-8?q?oKsYVJs0wzUDAiJF2AB9Vi+7YhNYMXJGq9QD/wGcRKtFd8ga2SeImtyWtKMsSEIdM?= =?utf-8?q?GUpo/+ghLNxMSJg5kU8jw=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=3DIZKCgUErBBXwi02d5uUy90QvL/B1lACkM5kxsCj2p2Y=3D=3B_b=3Dkwb8g4?= =?utf-8?q?d31R527OF6Ra+w/3l1Lm0BT9w5r47Ty3QhrFZUsISflx00UcayQP7xW1gvEAw4UcZ?= =?utf-8?q?MPP1A5pzW3rUM1NAi1byiJjQb1uHhcE7CnMRCwPlWmPHrjBLOC5XJjk7/rzOcQh+9?= =?utf-8?q?lvOKMvyrv9dc7T+DqxeRX8w63IFi6Az4ScVS0U2UKEJcI5/N2hT6apQwBz3832CTb?= =?utf-8?q?AK5EtU9pnHp0waltD2T0o1LqXFLuLsrUVyOEdB3Agi/x/6Rj7xZ2lDgQixR/hst91?= =?utf-8?q?xfd12QQmTupUhZkcn9LFcoKaHNmwTmG/ZHxDPHplLbCGNqW+n6MvXKLEy33Q/m8mE?= =?utf-8?q?WKmwBFrJxMg=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMe?= =?utf-8?q?ssage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCh?= =?utf-8?q?eck=3B_bh=3DIZKCgUErBBXwi02d5uUy90QvL/B1lACkM5kxsCj2p2Y=3D=3B_b?= =?utf-8?q?=3DN8VJQTJHw5j9lxYfCmA8S2lkd/VVgWycAG+L9X+bYko/dPAkAuWli209vc5r3S?= =?utf-8?q?XqUpJN22jIiHInKXS+Ss63SHuVVam5w0QVgbtrs5YMZa7V8LyVCciH1O7Ib1dDaEo?= =?utf-8?q?2AXFMXmf1hZoy9TRk8rObW5o45jpmxf2hUbdnYTBGppc=3D?=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3472.namprd19.prod.outlook.com (2603:10b6:208:18b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.16; Tue, 10 Mar 2020 20:14:52 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::c476:9aac:4d02:477c]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::c476:9aac:4d02:477c%5]) with mapi id 15.20.2793.013; Tue, 10 Mar 2020 20:14:52 +0000
From: "Black, David" <David.Black@dell.com>
To: Bob Briscoe <in@bobbriscoe.net>, Donald Eastlake <d3e3e3@gmail.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
CC: John Kaippallimalil <John.Kaippallimalil@huawei.com>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] Comments on draft-ietf-tsvwg-ecn-encap-guidelines-13
Thread-Index: AQHV3UGySdCE6Xpe/ESkXcPpovJh/ahCSCwAgAAWUfA=
Date: Tue, 10 Mar 2020 20:14:51 +0000
Message-ID: =?utf-8?q?=3CMN2PR19MB404578A43B43F7745ABC827A83FF0=40MN2PR19MB4?= =?utf-8?q?045=2Enamprd19=2Eprod=2Eoutlook=2Ecom=3E?=
References: <CAF4+nEGu9XEiXypPw0NK+f2N9QbBwyTJKXbViKWVScJhOW=vUA@mail.gmail.com> <CAF4+nEEB2-pz4ugW-m1-3gq9KH-fyt93sLZ9WFh4BkJqQPX7PA@mail.gmail.com> <56499dde-81f1-5bd7-fd7c-67a201376e6a@bobbriscoe.net>
In-Reply-To: <56499dde-81f1-5bd7-fd7c-67a201376e6a@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; =?utf-8?q?MSIP=5FLabel=5F17cb76b2-10b8-4fe1-93d4-2202842406cd=5FSiteId=3D94?= =?utf-8?q?5c199a-83a2-4e80-9f8c-5a91be5752dd=3B?= =?utf-8?q?MSIP=5FLabel=5F17cb76b2-10b8-4fe1-93d4-2202842406cd=5FOwner=3Ddav?= =?utf-8?q?id=2Eblack=40emc=2Ecom=3B_MSIP=5FLabel=5F17cb76b2-10b8-4fe1-93d4-?= =?utf-8?q?2202842406cd=5FSetDate=3D2020-03-10T20=3A14=3A50=2E8783566Z=3B?= MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [168.159.213.214]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e91ab393-d8a7-447b-b51b-08d7c52fb10a
x-ms-traffictypediagnostic: MN2PR19MB3472:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR19MB3472A4641BF35882BD4689BD83F?= =?utf-8?q?F0=40MN2PR19MB3472=2Enamprd19=2Eprod=2Eoutlook=2Ecom=3E?=
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 033857D0BD
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNjYwMDQpKDM0NjAwMikoMzk2MDAzKSgzNzYwMDIpKDEzNjAwMykoMzk4?= =?utf-8?b?NjA0MDAwMDIpKDE4OTAwMykoMTk5MDA0KSg1NTAxNjAwMikoMjkwNjAwMiko?= =?utf-8?q?71200400001=29=289686003=29=2886362001=29=28107886003=29=28669460?= =?utf-8?b?MDcpKDUyNTM2MDE0KSg0MzI2MDA4KSg1NjYwMzAwMDAyKSg4MTE1NjAxNCko?= =?utf-8?q?478600001=29=2881166006=29=2876116006=29=288936002=29=287696005?= =?utf-8?b?KSgzMTYwMDIpKDI2MDA1KSg3ODYwMDMpKDk2NjAwNSkoNjY0NzYwMDcpKDY1MDYw?= =?utf-8?b?MDcpKDg2NzYwMDIpKDUzNTQ2MDExKSg2NjU1NjAwOCkoNjQ3NTYwMDgpKDEx?= =?utf-8?q?0136005=29=2866446008=29=2854906003=29=28186003=29=2833656002=29?= =?utf-8?q?=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3472; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: dell.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?dKeNUohasCWOG34vzteLcQLTauln3bI?= =?utf-8?q?PTOo+AvRinao1YhPQc4/od/0+8KnaUTKxZkfTaq0qFhylWIfpBMmM0EFunmRX8N9d?= =?utf-8?q?gxHKRVaPkMQDCvBvQM79BdQp+5O5yg4qtL0kiRQTJoq5LlAGwYPmbHlloy0aK0LkG?= =?utf-8?q?a7g9FZBefk5imbC3ZxgWVPa3slUGAAyNIlkxkwbsJYNMiKrouA+ApGvOzlXEKWTWF?= =?utf-8?q?rnN7IUcvcBaltRkvQ2bmqh1hkZXJ+hyD/6ow4cDh8sBdpFF9ONOKQbpi1MqghC3HY?= =?utf-8?q?wNOKKyV4GvXvbTUPwbZQidlASJ+31VbTBGr5lcRlm/LQdMmLYKyhL+Nbjja7+xPh2?= =?utf-8?q?DTUAusOxZ9bM2JfrqP6SYjzO3IRsSxp+XyQJcKtvdWMUt8OPQSP22OEoX+YmyrTF3?= =?utf-8?q?v9RYBOlykQsvyIuC+din3QNdkZW/HzHp/YmmwarJKKhAyWpPyaW9ZaZRGlBKzYwAg?= =?utf-8?q?ymnOQc8X5OeGVPsbkKbmskoaUZAMHQ5MqyglUGiPMyd1766Q=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?QRUSxa6SeDSyCwMK3kih+xErJ/mWDy?= =?utf-8?q?wpSlwbHdMxnPiiqshk4z8/HIczSWTzuG23+yxSB9llfwmDIlD8wxYxZXZZKx72aMB?= =?utf-8?q?pkOIPGCijDmOA38JDMSqM4CyBb2yGRhb2THu24rCEG78xaBOsbpT03A=3D=3D?=
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB404578A43B43F7745ABC827A83FF0MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e91ab393-d8a7-447b-b51b-08d7c52fb10a
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 20:14:52.0010 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?guBKqlg190nuTkwzaJEtn?= =?utf-8?q?70Bhn4RA72BORLuVvJgq/SUzRbWlgDogXSKxbI39/f/8xAjQOODeenkp416PEDZZg?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3472
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-10_13:2020-03-10, 2020-03-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 priorityscore=1501 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003100118
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 phishscore=0 clxscore=1015 priorityscore=1501 spamscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003100118
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/yN-qexaxRq-gqfWprPyKzV0aFgY>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-ecn-encap-guidelines-13
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: Tue, 10 Mar 2020 20:15:53 -0000

Writing as draft shepherd …

> Section 4.4, point 1, first starred subpoint, there is something odd about
>     "the packet MAY be forwarded, but it SHOULD be dropped".
> Any better (I've added some of the context for the list)?:

>          If the congestion marking is the

>          most severe possible, the packet MUST be dropped.  However, if

>          congestion can be marked with multiple levels of severity and

>          the packet's marking is not the most severe, this requirement

>          can be relaxed to: the packet SHOULD be dropped, but it MAY be

>          forwarded.

That’s not much of an improvement.  Here’s the full -13 text to provide the context:

1.  If the arriving inner header is a Not-ECN-PDU it implies the L4
       transport will not understand explicit congestion markings.
       Then:

       *  If the outer header carries an explicit congestion marking,
          drop is the only indication of congestion that the L4
          transport will understand.  If the congestion marking is the
          most severe possible, the packet MUST be dropped.  However, if
          congestion can be marked with multiple levels severity and the
          packet's marking is not the most severe, the packet MAY be
          forwarded, but it SHOULD be dropped.

Assuming that we don’t tinker with the technical content of the last sentence, the better thing to
do with a statement of a “SHOULD” requirement is to explain what may happen if something else
is done.   I  think it’s implicit that a packet that is not dropped gets forwarded instead, so here’s
a suggestion for better text:


          If the congestion marking is the

          most severe possible, the packet MUST be dropped.  However, if

          congestion can be marked with multiple levels of severity and

          the packet's marking is not the most severe, this requirement

          can be relaxed to: the packet SHOULD be dropped, as forwarding

          all such packets may conceal the network congestion that they

          from the L4 transport that does not understand explicit congestion

          markings.

Thanks, --David

From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Bob Briscoe
Sent: Tuesday, March 10, 2020 1:29 PM
To: Donald Eastlake; tsvwg@ietf.org
Cc: John Kaippallimalil
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-ecn-encap-guidelines-13


[EXTERNAL EMAIL]
Donald,

Thank you for taking the time to review this (rather long) draft.
Apologies for not getting to your review until now.
On 06/02/2020 23:03, Donald Eastlake wrote:
Hi,

I'm not subscribed to the tsvwg mailing list but I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines-13 and though you might be interested in my comments.

Overall, this is a very clear and well-written draft. The comments below are minor. Whether or not they are incorporated into the draft, I hope that it can be advanced soon.

Section 1. I suggest just deleting the one occurrence in the draft of "[RFC1323]" and the corresponding reference section entry. It seems unnecessary and just leads to a nits checker warning which will have to be explained, etc.

Section 1.1. Very minor but I believe the usual way, inside a draft, to refer to the RFC which that draft might become is "[this document]" (without the double quotes) rather than "[RFCXXXX]". Changing to the more common notation would, I believe, enable the RFC Editor note to be removed as "[this document]" is well understood by the RFC Editor.

Section 2. The initial paragraph on implementation keywords should be updated to the following as per RFC 8174:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
Done all the above
(BTW, I always baulk at having to cite RFC8174, when the following 12 words succinctly state the sum total of its content.)



Section 2. Suggest putting the Terminology entries in alphabetic order..
I haven't done this. They are more for reading through than for being looked up individually, most of them fall into logical little groups, and there are not so many that it's hard to find one.



Section 4.2, page 18. "802.1p" has been merged into 802.1Q ages ago. Values of the priority field are commonly referred to in IEEE 802.1 as Priority Code Points (PCPs) and in any case this seems a bit inconsistent to the way that the merger of 802.1ah into 802.1Q is recognized in the draft. Perhaps the last sentence of Section 4.2 could be: "An operator can define certain [IEEE802.1Q] Priority Code Points to indicate non-QCN frames and an ingress bridge is required to map arriving not-QCN-capable IP packets to one of these code points."
OK. I've taken on board the spirit of your edit, but changed it slightly:

   An operator can define certain

   Priority Code Points (PCPs [IEEE802.1Q]; previously 802.1p) to

   indicate non-QCN frames and an ingress bridge is required to map

   arriving not-QCN-capable IP packets to one of these non-QCN PCPs.
This is then consistent with the other references to 802.1Q, which also give the number of the constituent part before it was wrapped up into the mega-standard. If you think this is clumsy, pls say. I did it this way, because many people know these 802.1 drafts much better by their old name (well, for 'many people' read 'me', or perhaps read it as 'old farts like me').



Section 4.4, point 1, first starred subpoint, there is something odd about "the packet MAY be forwarded, but it SHOULD be dropped".
Any better (I've added some of the context for the list)?:

          If the congestion marking is the

          most severe possible, the packet MUST be dropped.  However, if

          congestion can be marked with multiple levels of severity and

          the packet's marking is not the most severe, this requirement

          can be relaxed to: the packet SHOULD be dropped, but it MAY be

          forwarded.

Section 7. It doesn't matter much but IANA would prefer that sections saying there are no IANA actions be left in the final RFC (see Section 9.1 of RFC 8126).
I'm learning something new every day.



Section 9. Should "the document" in the first line of this section by "this document"?
Yes. Done.


Appendix A. I did not review this update history.

Authors' Addresses: I don't think Pat Thaler can be listed as a front page "author" in the RFC sense unless at least an email address is listed for her. All authors should be pollable about IPR they know and when the draft gets to the AUTH48 state before RFC publication, the RFC editor must be able to contact all the authors. If no email address is known, she should be moved to a "Contributors" section or the like.
Yes. I discovered that (too late) last night, when the draft got rejected on this point!
I've added a Contributors section for her.

Thank you again.



Bob






--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/