[bfcpbis] FW: [AD] 2119/8174 related question - Re: REMINDER Re: AUTH48 [JM]: RFC 8855 <draft-ietf-bfcpbis-rfc4582bis-16.txt> NOW AVAILABLE

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Thu, 03 December 2020 18:42 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D522E3A03F4 for <bfcpbis@ietfa.amsl.com>; Thu, 3 Dec 2020 10:42:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=a0bsVX1B; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HsmBqcGW
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 trHTvWGusdFa for <bfcpbis@ietfa.amsl.com>; Thu, 3 Dec 2020 10:42:37 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4CD3A03F3 for <bfcpbis@ietf.org>; Thu, 3 Dec 2020 10:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=105929; q=dns/txt; s=iport; t=1607020957; x=1608230557; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=eno10FN4iIHNYwxh2whPy5ARq8RxeZ2iiDcOujyE9WQ=; b=a0bsVX1BtsjsQFAAZEU6RU9CfxSqQ6PW6DN9GKkzeLJNKJ51HNpsijs/ 8J0MIWrRdvm2mdytzQCTPcpUDeWHm6MInT7su2pacel7eGYAaacJ25tZY 40QKe/aNVZgt6zMjqCsPklakNoBcbvoCZfhrgrAuAHLAegQW87Drg1sjD Y=;
X-IPAS-Result: =?us-ascii?q?A0DsBQDCL8lfkJ1dJa1iHQEBAQEJARIBBQUBgg+BIy8jB?= =?us-ascii?q?ih8Wy8uCoQyg0gDjTQlA4oXhHKJf4JTA08FCwEBAQ0BARgBCgoCBAEBhAZEA?= =?us-ascii?q?heBfgIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQGGOAELhXIBAQECA?= =?us-ascii?q?QEBARAICR0BASkDDA8CAQgRAwECASABAgQDAgICHwYLFAcBAQUDAgQTIoMEA?= =?us-ascii?q?YF+VwMOIAEOogQCgTyIaXaBMoMEAQEFhSMNC4IQAwaBOIJzg3aBBoVRG4IAg?= =?us-ascii?q?REnDBCBV34+gQSBF0IBAQEBgUUvCQ0JgmEzgiyBTxpYBgFeAQMUFBsOAiEHM?= =?us-ascii?q?gIoRBIGBAMeCgEeCZASgneHJowokFlXCoJykAaGF4UYAx+DIYohBYQvjXmCN?= =?us-ascii?q?oFfhDGNYoICi3uOTwEYAYQvAgQCBAUCDgEBBYFtIYFZcBU7KgGCPlAXAg2OI?= =?us-ascii?q?QwMAgkUbgEIgkOBOINchUR0AgE0AgYBCQEBAwl8jkEBgRABAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3Atu+iMRyF1jSkn2HXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWFt/RgkFGPWp/UuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHC2LUYTH9zxNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,390,1599523200"; d="scan'208,217";a="623414053"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Dec 2020 18:42:35 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B3IgZuD020976 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <bfcpbis@ietf.org>; Thu, 3 Dec 2020 18:42:35 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Dec 2020 12:42:34 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Dec 2020 12:42:33 -0600
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 3 Dec 2020 13:42:33 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KP9cRsfHnswru9GnvTiz1O/r307XgY8mCOfed6ySos+/y9p2oXEzdwDAY9FI4SSurx/PNY8Xwcnd/rg8ei9FxB0vukrCp+5xnmp9aXGnhl8Ifa/lUlFRp2SUIiEs35cz9xp0HdQnOaScAMCxpXXHdIwhiAAwz5lQqDImUXy2CkbpkSOkuvHBe31wXJ9fgUxThZF3KQfcjZhapyJfdLyt9Ag3td6oyZrunxeUy2/zqI1w0scxn/nCOYEhAaBUGABEBhC+BBlvqJSK75X4uYpsY8yS/HvkGp9tQqaBvnszj2oZG8h9JzLgstF4sfSuJx6TExQKMoYr+YS9bb72GoUMqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eno10FN4iIHNYwxh2whPy5ARq8RxeZ2iiDcOujyE9WQ=; b=P8B65QP3lSvpSGq8x2pwj4uAc3V+DCdSzx6id8Xr0qv07GSaIqcmHOo4JUAJhHuhv5NxzfcI59ZzBgVWugl2EK3GVT9AkaBZjh2SszbC/oHAd260a/ohpZ76OkG/vgen9MU+6KQfyprgj/G1B390oTky5tX3hLFlBZMqP5XOFaPqD8scvkSQyO6BFpzknXAn6C8rav0tqTXFW0U0KSnoQVxwDCVHsquslYTiBX2cdxZWGX/ha5e4dmWM2UMybIhpjKdBtNm8I7qrQ4fIVWYFNPJ4VsEV7gwP4v6esEKNKsysNEHyngKKpBk/+HToA7cOj+/Gk1wGWrW0cMxQDCLTgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eno10FN4iIHNYwxh2whPy5ARq8RxeZ2iiDcOujyE9WQ=; b=HsmBqcGWDuC28fHQbxWbkekXjeKT7MKVgY9/o/a8MJ00D1Iwdpaj3+VY+a0Es67vahwCnclBRBWFciISA4I0Neqq6X7W+gNE1Y5a4cQwKf/uRbrugj5TcYRq5VDNdHZUfbBTAPsTM7/75iZUUkx7uMjGXNpWau2hbjs3Re875/U=
Received: from SJ0PR11MB5053.namprd11.prod.outlook.com (2603:10b6:a03:2af::17) by SJ0PR11MB4800.namprd11.prod.outlook.com (2603:10b6:a03:2af::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Thu, 3 Dec 2020 18:42:29 +0000
Received: from SJ0PR11MB5053.namprd11.prod.outlook.com ([fe80::49f:a753:85f7:5091]) by SJ0PR11MB5053.namprd11.prod.outlook.com ([fe80::49f:a753:85f7:5091%4]) with mapi id 15.20.3611.034; Thu, 3 Dec 2020 18:42:29 +0000
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [AD] 2119/8174 related question - Re: REMINDER Re: AUTH48 [JM]: RFC 8855 <draft-ietf-bfcpbis-rfc4582bis-16.txt> NOW AVAILABLE
Thread-Index: AQHWm/jbBbo1lZ0H9UKIO05ed/XhaKmsIeuAgA4ns4CAK5fngIAAIPWA//+HkoA=
Date: Thu, 3 Dec 2020 18:42:29 +0000
Message-ID: <1F7B4C6E-6383-4350-856D-10A3D6CF95E7@cisco.com>
References: <20200505062106.40196F4072C@rfc-editor.org> <45c39325-5f5b-6161-304e-91beae81dd20@ntlworld.com> <089754DF-62D6-4544-9B9D-FA3DD18C5F57@cisco.com> <AM0PR07MB38607B50A6FE921CD2288C6493200@AM0PR07MB3860.eurprd07.prod.outlook.com> <620E4721-DE3D-4091-8E4D-5AB7535478C4@cisco.com> <AM0PR07MB3860B2C54BCAB8CDF86BA23C93200@AM0PR07MB3860.eurprd07.prod.outlook.com> <D5B11705-0744-4FFB-8244-EF38FCBB27F2@cisco.com> <2D1DB7B6-184E-4B96-9E29-4127AF5B6A00@gmail.com> <84F3EE2D-9ED9-454F-99B0-2FA7C6DAD54F@cisco.com> <CAD5OKxtoh0ptboh3E-nrQsvQXZKZk+Je+S+5O3Moi_2hPWSa-w@mail.gmail.com> <FA9141D6-1581-4B52-B7B2-91B2B6CC8A14@cisco.com> <312fe819-6713-0ef5-9af1-f737970c3ee8@amsl.com> <2DFE829C-DCF0-49E0-B4D3-94975FF8AFE1@cisco.com> <0c83e327-edbb-1f18-6d95-25e397d5386d@amsl.com> <EC7A839D-E950-4F64-8C1B-F2E942DBAAA5@cisco.com> <edec677d-f85f-1731-937c-6c626ca4eca1@amsl.com> <f08b048a-5d09-6aa0-68d5-5caf69bbc143@amsl.com> <68a6e7c5-a271-a945-7321-a20d0e064b57@amsl.com> <a64269dc-6a7e-9026-53fd-087fe55aeb12@amsl.com> <CD5ACEE5-2923-4C93-824E-C24BD5A947BC@amsl.com>
In-Reply-To: <CD5ACEE5-2923-4C93-824E-C24BD5A947BC@amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [24.23.180.61]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 406f24fc-6ae9-4cf2-b9f6-08d897bb304f
x-ms-traffictypediagnostic: SJ0PR11MB4800:
x-microsoft-antispam-prvs: <SJ0PR11MB4800E78FACC6EDD8B6E9D050B2F20@SJ0PR11MB4800.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zXsFC5tDh0Ime9gISEsLAtn8uO9IbDQm3Xd+7FaucePhQbW7SG6oEOF0urh0ixtYv5Imh3OzhQf8QyIoP9KoDOsjwsQWcvveyGjB4A1awj9zublKXPoYqkwb6pCZEIs9RibERMr31BNUySoerlXcq67YQ8CQwQUntekduU58DwNHpY9zbow2eL3jKAJyrmr/KbQdGh87zlNTOstgMQ69d1dG6v02Hz2Au0fTYgdpNMQ/9Ch7FM0QQ0kuWFJkUVVjKqxkCfm7jDOImwxwzR6pXRrsluxyZj+2cqXkPzEF/rkMz+88EqsoWN3qGmpk7GKhFRkC7Kgr3e/NkKc3d0503AuzA1BwX0oga/WVMKKW3ziWldC1c3C+jDluYHHXJ6S0xy9UTmq/aQKoKqSv9sljJdfRM8CDYAqDvUauN1GQrrTQ8n9GsEeScdQWlG/GZOsj93mCGOfhTdqZNmarltgxXg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB5053.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(39860400002)(366004)(346002)(396003)(30864003)(86362001)(53546011)(186003)(6506007)(66476007)(8936002)(5660300002)(316002)(966005)(478600001)(36756003)(6512007)(6916009)(6486002)(66946007)(76116006)(66446008)(166002)(64756008)(71200400001)(26005)(8676002)(21615005)(66556008)(83380400001)(2906002)(33656002)(2616005)(45980500001)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?L2FoRlU3OVhHb3ZKMndvZDRBZTg4ZjlGeG9ZQnRGRHEyY3h6N3IyeTRRSXZw?= =?utf-8?B?SWdzbUcvYnBqNGFmbm5vR0VWSWZKdEpyQUxkekpWNFllaXRpdEFRalc3RjNH?= =?utf-8?B?Y0ZOTE9ZeDcvdmJGSkUzL3NoY3lnbWkxRU94Mm8vWlRyb21reGF2dTBqRU5F?= =?utf-8?B?cUVWRFN1eFVOQjVWeVRNdUdoTTV0Rmd1ZWhpczBqME1qY3VyVHF3NkxudnRt?= =?utf-8?B?cFZEeW94a2planhGejJPT2ZoUkgzNVpieEhWL1ZNeG5haFF2TEhDK3RuaCtx?= =?utf-8?B?aUQvdFAxeVM0aEIvQmhVVlRZUG5HbGU5azlmUkRBRlhsbkQrU1dZalhIWkJ5?= =?utf-8?B?SCtRaTZBTkZsNDZ5RjFqSUo4S0FHaDIvVmx2Qis3OWJYV0gzRnZGYzAyalh0?= =?utf-8?B?VlI4MkNQU1FYTjVhVUNtckdEV0hvbXZPVVZzaTM3REJQRnJMdXZUZW1tWTYr?= =?utf-8?B?SEFnYk1qeXl5TUZtaFludzRXOVI2T1BZSEZHUWFOV0xZckZvM3VrWjJCcVdG?= =?utf-8?B?QjZYNmJ4Vyt0TU5BaGY3ajlSdmRBV0owU0dKSVMzZ1hHaUx0Q1oweHBXQVl6?= =?utf-8?B?S1VHd2xCeXoyR1ZlY05ubjlCbzhya2Q3MmVqMFJZOHNaOEhINmdaYlZzaTJI?= =?utf-8?B?Vm1GU0x3bWVqeHRJY01PNWI0UW5mcTd3bWJYc0NTbnRiS3k4enVrLzhJSGJH?= =?utf-8?B?aHlOS0JHK1BqVWMxSEVZSlExOXREV0N5UkV2bG9IbmFVd0RSTjlpYnJBSjV0?= =?utf-8?B?d0h4TS9yT2JFVVVPZmx6QjFidkF4bThVcDZPNFFiZm5CcmNHTms1SkhNSlJn?= =?utf-8?B?L3I2eEhCYmJlTFBFU1J1K3YrdzdrYjM0aERMcGw5NzM5RlFSWXozT1pjbGNW?= =?utf-8?B?bDRRZlZRYUM5RjV3blp4b2M3NEdJSWNlWWk1SlFJUXhQM2UwMG1FVEU5U2RT?= =?utf-8?B?RlhxWFVpMFFNQ1FaMzJuTnJIaEMyUTFNK2dXaklad25odEJobEdOaUkvODI5?= =?utf-8?B?VzhMRHhBWG01UXRhQXdwckExNjBnZTg3dXAxMFdJT3FXNDdZUTBGNkM0cHpF?= =?utf-8?B?Qzl2RGk5OXpMcFlycEVWQnhXUXBqbHFCWnpkWXUydXc2QzdHcmJjUjdjU3R6?= =?utf-8?B?N2dORDIvVElzeUFtZFJpRVdiNDJ6UlZ0Mm9PeWM2Y201aHhCSTlldXVwdXBW?= =?utf-8?B?aTI0bUY5V0Z5YjV4aHI3cVh6ZmRLQjZOVGl4T2MrRHNPbytWaWNVTWlsVnd5?= =?utf-8?B?TXZKbmxSU3c2ZXZ6K0VQMlJ1U1ljcmZ4RFppUDliS3c0WUJ3MTRMK3dpL3FN?= =?utf-8?Q?OYTJ6hV849A4+Sd7QxpbKMxbz9/vfKdcRl?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_1F7B4C6E63834350856D10A3D6CF95E7ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5053.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 406f24fc-6ae9-4cf2-b9f6-08d897bb304f
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 18:42:29.7477 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WN8ufTWmXWDs/N+fkYBLFaJEoHGOCpZ6pWbUFPrpRt4Id/tVn9ZyHHPkPU0aYWv2VmAw83FQqZFl3m00TQYfZg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4800
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/gyRreCreuVewIQum87A5X1HjDyo>
Subject: [bfcpbis] FW: [AD] 2119/8174 related question - Re: REMINDER Re: AUTH48 [JM]: RFC 8855 <draft-ietf-bfcpbis-rfc4582bis-16.txt> NOW AVAILABLE
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 18:42:42 -0000

Hi Working Group,

As a result of replacing the reference to RFC 2119 with one to RFC 8174, which aims to reduce the ambiguity of normative language by clarifying that only UPPERCASE usage of the key words have the defined special meanings, there is a change of one occurrence of “must” to “MUST”.
Please review this change and respond with any concerns with this change within the next two weeks. If there are no concerns, we will move forward with the change.

Thanks,
Charles

From: Sandy Ginoza <sginoza@amsl.com>
Date: Thursday, December 3, 2020 at 9:53 AM
To: "bfcpbis-ads@ietf.org" <bfcpbis-ads@ietf.org>
Cc: "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>rg>, Alan Ford <alan.ford@gmail.com>om>, Charles Eckel <eckelcu@cisco.com>om>, "Charles Eckel (eckelcu)" <eckelcu=40cisco.com@dmarc.ietf.org>rg>, Christer Holmberg <christer.holmberg@ericsson.com>om>, Keith Drage <drageke@ntlworld.com>om>, Roman Shpount <roman@telurix.com>om>, Joerg Ott <jo@comnet.tkk.fi>fi>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>om>, Mary Barnes <mary.ietf.barnes@gmail.com>om>, "tom@kristensen.larvik.no" <tom@kristensen.larvik.no>no>, C238 <c238@rfc-editor.org>rg>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [AD] 2119/8174 related question - Re: REMINDER Re: AUTH48 [JM]: RFC 8855 <draft-ietf-bfcpbis-rfc4582bis-16.txt> NOW AVAILABLE

Authors and ADs,

We have updated the document as described below.

*ADs, please let us know if you approve this update and the use of the keywords paragraph defined in RFC 8174.

The current files are available here:
   https://www.rfc-editor.org/authors/rfc8855.xml
   https://www.rfc-editor.org/authors/rfc8855.txt
   https://www.rfc-editor.org/authors/rfc8855.pdf
   https://www.rfc-editor.org/authors/rfc8855.html

Diffs highlighting just the change described below:
   https://www.rfc-editor.org/authors/rfc8855-lastdiff.html
   https://www.rfc-editor.org/authors/rfc8855-lastrfcdiff.html


AUTH48 diff:
   https://www.rfc-editor.org/authors/rfc8855-auth48diff.html


Comprehensive diff:
   https://www.rfc-editor.org/authors/rfc8855-diff.html


Note that the publication date and that of the cluster references will be updated closer to the date of publication.

Thanks,
RFC Editor/sg


From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com<mailto:eckelcu@cisco.com>>
Subject: Re: [C238] [Author Action Requested] Cluster-wide question regarding the RFC 2119/8174 keywords paragraph]
Date: November 23, 2020 at 3:05:59 PM PST
To: RFC Editor <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>, C238 <c238@rfc-editor.org<mailto:c238@rfc-editor.org>>
Cc: "avtcore-chairs@ietf.org<mailto:avtcore-chairs@ietf.org>" <avtcore-chairs@ietf.org<mailto:avtcore-chairs@ietf.org>>, "jonathan.lennox@8x8.com<mailto:jonathan.lennox@8x8.com>" <jonathan.lennox@8x8.com<mailto:jonathan.lennox@8x8.com>>, "roni.even@mail01.huawei.com<mailto:roni.even@mail01.huawei.com>" <roni.even@mail01.huawei.com<mailto:roni.even@mail01.huawei.com>>, "avtcore-ads@ietf.org<mailto:avtcore-ads@ietf.org>" <avtcore-ads@ietf.org<mailto:avtcore-ads@ietf.org>>, "John R. Levine" <johnl@iecc.com<mailto:johnl@iecc.com>>, Barry Leiba <barryleiba@computer.org<mailto:barryleiba@computer.org>>

For draft-ietf-bfcpbis-rfc4582bis, there is one case is which "must" is used that I believe was intended to be normative.

  Fragment Length:  This optional field is present only if the F flag
     is set and contains a 16-bit value that specifies the number of
     4-octet units contained in this fragment, excluding the COMMON-
     HEADER.  BFCP entities that receive message fragments that,
     individually or collectively, exceed the Payload Length value MUST
     discard the message.  Additionally, if the receiver is a floor
     control server, it must also send an Error message with parameter
     value 13 (Incorrect Message Length)

My vote is to change "must" to "MUST" in the second to last line, and add a period at the end of the sentence, too.
Other than that, I believe the reference to RFC 8174 matches the intent of the working group and the authors.

Cheers,
Charles



On Dec 3, 2020, at 7:55 AM, Jean Mahoney <jmahoney@amsl.com<mailto:jmahoney@amsl.com>> wrote:

Keith,
Just a reminder that we await word from you regarding this document's readiness for publication as an RFC.
  https://www.rfc-editor.org/authors/rfc8855.html
  https://www.rfc-editor.org/authors/rfc8855.pdf
  https://www.rfc-editor.org/authors/rfc8855.txt
  https://www.rfc-editor.org/authors/rfc8855-diff.html
Best regards,
RFC Editor/jm

On 11/5/20 4:12 PM, Jean Mahoney wrote:
Keith,
We do not believe we have heard from you regarding this document's readiness for publication.

Please let us know if any updates are needed or if the document is ready for publication.
Best regards,
RFC Editor/jm

On 10/27/20 5:02 PM, Jean Mahoney wrote:
Keith,
We do not believe we have heard from you regarding this document's readiness for publication.

Please let us know if any updates are needed or if the document is ready for publication.
Best regards,
RFC Editor/jm

On 10/6/20 10:53 AM, Jean Mahoney wrote:
Keith,
We do not believe we have heard from you regarding this document's readiness for publication.

Please let us know if any updates are needed or if the document is ready for publication.
Best regards,
RFC Editor/jm

On 9/29/20 9:37 AM, Charles Eckel (eckelcu) wrote:
The changes look good to me.

Thanks,
Charles

From: Jean Mahoney <jmahoney@amsl.com><mailto:jmahoney@amsl.com>
Date: Monday, September 28, 2020 at 3:39 PM
To: Charles Eckel <eckelcu@cisco.com><mailto:eckelcu@cisco.com>, Roman Shpount <roman@telurix.com><mailto:roman@telurix.com>, "Charles Eckel (eckelcu)" <eckelcu=40cisco.com@dmarc.ietf.org><mailto:eckelcu=40cisco.com@dmarc.ietf.org>
Cc: Alan Ford <alan.ford@gmail.com><mailto:alan.ford@gmail.com>, Joerg Ott <jo@comnet.tkk.fi><mailto:jo@comnet.tkk.fi>, "bfcpbis-chairs@ietf.org"<mailto:bfcpbis-chairs@ietf.org> <bfcpbis-chairs@ietf.org><mailto:bfcpbis-chairs@ietf.org>,"bfcpbis@ietf.org"<mailto:bfcpbis@ietf.org> <bfcpbis@ietf.org><mailto:bfcpbis@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com><mailto:gonzalo.camarillo@ericsson.com>, Keith Drage <drageke@ntlworld.com><mailto:drageke@ntlworld.com>, "bfcpbis-ads@ietf.org"<mailto:bfcpbis-ads@ietf.org> <bfcpbis-ads@ietf.org><mailto:bfcpbis-ads@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com><mailto:christer.holmberg@ericsson.com>, Mary Barnes <mary.ietf.barnes@gmail.com><mailto:mary.ietf.barnes@gmail.com>, "tom@kristensen.larvik.no"<mailto:tom@kristensen.larvik.no> <tom@kristensen.larvik.no><mailto:tom@kristensen.larvik.no>, RFC Editor <rfc-editor@rfc-editor.org><mailto:rfc-editor@rfc-editor.org>
Subject: Re: [bfcpbis] AUTH48 [JM]: RFC 8855 <draft-ietf-bfcpbis-rfc4582bis-16.txt> NOW AVAILABLE

Charles,
We have moved the RFC 8445 reference to the Normative References section.
  The files have been posted here:
   https://www.rfc-editor.org/authors/rfc8855.txt
   https://www.rfc-editor.org/authors/rfc8855.pdf
   https://www.rfc-editor.org/authors/rfc8855.html
   https://www.rfc-editor.org/authors/rfc8855.xml
   https://www.rfc-editor.org/authors/rfc8855-lastdiff.html (this change)
   https://www.rfc-editor.org/authors/rfc8855-auth48diff.html (AUTH48 changes)
   https://www.rfc-editor.org/authors/rfc8855-diff.html (all changes)
Best regards,
RFC Editor/jm

On 9/28/20 5:13 PM, Charles Eckel (eckelcu) wrote:
Hi Jean,

Yes, please do.

Thanks,
Charles

From: Jean Mahoney <jmahoney@amsl.com><mailto:jmahoney@amsl.com>
Date: Monday, September 28, 2020 at 3:10 PM
To: Charles Eckel <eckelcu@cisco.com><mailto:eckelcu@cisco.com>, Roman Shpount <roman@telurix.com><mailto:roman@telurix.com>, "Charles Eckel (eckelcu)" <eckelcu=40cisco.com@dmarc.ietf.org><mailto:eckelcu=40cisco.com@dmarc.ietf.org>
Cc: Alan Ford <alan.ford@gmail.com><mailto:alan.ford@gmail.com>, Joerg Ott <jo@comnet.tkk.fi><mailto:jo@comnet.tkk.fi>, "bfcpbis-chairs@ietf.org"<mailto:bfcpbis-chairs@ietf.org> <bfcpbis-chairs@ietf.org><mailto:bfcpbis-chairs@ietf.org>, "bfcpbis@ietf.org"<mailto:bfcpbis@ietf.org> <bfcpbis@ietf.org><mailto:bfcpbis@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com><mailto:gonzalo.camarillo@ericsson.com>, Keith Drage <drageke@ntlworld.com><mailto:drageke@ntlworld.com>, "bfcpbis-ads@ietf.org"<mailto:bfcpbis-ads@ietf.org> <bfcpbis-ads@ietf.org><mailto:bfcpbis-ads@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com><mailto:christer.holmberg@ericsson.com>, Mary Barnes <mary.ietf.barnes@gmail.com><mailto:mary.ietf.barnes@gmail.com>, "tom@kristensen.larvik.no"<mailto:tom@kristensen.larvik.no><tom@kristensen.larvik.no><mailto:tom@kristensen.larvik.no>, RFC Editor <rfc-editor@rfc-editor.org><mailto:rfc-editor@rfc-editor.org>
Subject: Re: [bfcpbis] AUTH48 [JM]: RFC 8855 <draft-ietf-bfcpbis-rfc4582bis-16.txt> NOW AVAILABLE

Hi Charles,
Shall I proceed with moving the reference to RFC 8445 from informative to normative?
Thanks!
RFC Editor/jm

On 9/22/20 3:26 PM, Charles Eckel (eckelcu) wrote:
Thanks Roman.
Your review and confirmation of this approach is very helpful and is much appreciated.

Cheers,
Charles

From: Roman Shpount <roman@telurix.com><mailto:roman@telurix.com>
Date: Tuesday, September 22, 2020 at 1:20 PM
To: "Charles Eckel (eckelcu)" <eckelcu=40cisco.com@dmarc.ietf.org><mailto:eckelcu=40cisco.com@dmarc.ietf.org>
Cc: Alan Ford <alan.ford@gmail.com><mailto:alan.ford@gmail.com>, Joerg Ott <jo@comnet.tkk.fi><mailto:jo@comnet.tkk.fi>, "bfcpbis-chairs@ietf.org"<mailto:bfcpbis-chairs@ietf.org> <bfcpbis-chairs@ietf.org><mailto:bfcpbis-chairs@ietf.org>, "bfcpbis@ietf.org"<mailto:bfcpbis@ietf.org> <bfcpbis@ietf.org><mailto:bfcpbis@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com><mailto:gonzalo.camarillo@ericsson.com>, Keith Drage <drageke@ntlworld.com><mailto:drageke@ntlworld.com>, "bfcpbis-ads@ietf.org"<mailto:bfcpbis-ads@ietf.org> <bfcpbis-ads@ietf.org><mailto:bfcpbis-ads@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com><mailto:christer.holmberg@ericsson.com>, Jean Mahoney <jmahoney@amsl.com><mailto:jmahoney@amsl.com>, Mary Barnes <mary.ietf.barnes@gmail.com><mailto:mary.ietf.barnes@gmail.com>, "tom@kristensen.larvik.no"<mailto:tom@kristensen.larvik.no> <tom@kristensen.larvik.no><mailto:tom@kristensen.larvik.no>, RFC Editor <rfc-editor@rfc-editor.org><mailto:rfc-editor@rfc-editor.org>
Subject: Re: [bfcpbis] AUTH48 [JM]: RFC 8855 <draft-ietf-bfcpbis-rfc4582bis-16.txt> NOW AVAILABLE
Resent-From: <alias-bounces@ietf.org><mailto:alias-bounces@ietf.org>
Resent-To: Keith Drage <drageke@ntlworld.com><mailto:drageke@ntlworld.com>, Charles Eckel <eckelcu@cisco.com><mailto:eckelcu@cisco.com>
Resent-Date: Tuesday, September 22, 2020 at 1:20 PM

Hi Charles,

Per your request, I have reviewed this as and this looks like a correct way to proceed.

Best Regards,
_____________
Roman Shpount


On Thu, Sep 17, 2020 at 4:09 PM Charles Eckel (eckelcu) <eckelcu=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Great, thanks Alan.

Cheers,
Charles

On 9/17/20, 11:27 AM, "Alan Ford" <alan.ford@gmail.com<mailto:alan.ford@gmail.com>> wrote:

    Charles, all,

    This seems the correct way to proceed. These are clearly normative references, and as regards 5389 vs 8489, 8445 references 5389 normatively anyway so if we changed that we would diverge from 8445.

    Best regards,
    Alan

    > On 15 Sep 2020, at 16:53, Charles Eckel (eckelcu) <eckelcu=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
    >
    > Thanks Christer.
    >
    > To recap, the updated proposal is to:
    >
    > 1) maintain the normative reference to RFC 5389 STUN rather than replace it with a reference to RFC 8489
    > 2) update the reference to RFC 5245 ICE to RFC 8445 ICE (this change has already been made a result of AUTH 48)
    > 3) make the informative reference to RFC 8445 ICE a normative reference to be consistent with the normative reference to RFC 5389 STUN and with the normative reference to RFC 8845 ICE in rfc4583bis.
    >
    > Christer, please confirm if I have capture this correctly.
    > Everyone else, your feedback here is greatly appreciated as well.
    >
    > Cheers,
    > Charles
    >
    > On 9/15/20, 8:13 AM, "Christer Holmberg" <christer.holmberg=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>> wrote:
    >
    >    Hi,
    >
    >    ...
    >
    >>>> 2) make the reference to RFC 5389/STUN an informative reference as is already done for RFC 5245/ICE
    >>>
    >>> My suggestion would actually be to update the ICE reference to RFC 8445. Again, that would align with other C238 cluster documents that reference ICE.
    >>
    >> [cue] Good point. This reference has already been updated to RFC 8445 as part of AUTH-48.
    >
    >    Good.
    >
    >>> And, in RFC 8445 STUN is a *normative* reference.
    >>
    >> [cue] In rfc4582bis, the reference to ICE is currently Informative, whereas the reference to STUN is Normative. I believe they should either both be Normative or both be Informative.
    >> Do you happen to know which way would be more consistent with similar references to STUN/ICE in cluster C238? In rfc4583bis, the reference to ICE is currently Normative.
    >
    >    Correct. rfc4583bis actually defines ICE procedures for BFCP, so Normative is fine.
    >
    >    4582bis contains the following sentence:
    >
    >       "In order to facilitate the initial establishment of NAT bindings, and
    >       to maintain those bindings once established, BFCP entities using an
    >       unreliable transport are RECOMMENDED to use STUN [12] Binding
    >       Indication for keep-alives, as described for ICE [17]."
    >
    >    As you can see, it is actually described in the ICE spec on how to use STUN. So, therefore I agree that both should be either Normative or Informative. And, since there is a "RECOMMENDED", I assume that means they would have to be Normative.
    >
    >    Regards,
    >
    >    Christer
    >
    >
    >
    >        On 5/21/20, 1:55 PM, "Keith Drage" <drageke@ntlworld.com<mailto:drageke@ntlworld.com>> wrote:
    >
    >            I do note that the normative requirement is at SHOULD strength.
    >
    >            However there are no statements that support an implementor to decide
    >            under what conditions the requirement can be ignored, or the
    >            consequences of ignoring, one or other of which should really be there.
    >
    >            The lack of that information does not help in trying to evaluate the
    >            consequences of updating the reference, versus leaving the reference as
    >            it is - note that there is a risk both ways.
    >
    >            The quick review I did, resulted in my feeling that the upgrade would be
    >            OK, but I am not an expert in that area. Certainly I think either way it
    >            should go to the WG for a quick review.
    >
    >            Keith
    >
    >            On 21/05/2020 19:09, Jean Mahoney wrote:
    >> Hi Charles,
    >>
    >> On 5/21/20 11:31 AM, Charles Eckel (eckelcu) wrote:
    >>> Hi Jean,
    >>>
    >>> I am more comfortable sticking with RFC 5389 at this point in time.
    >>
    >>
    >> Ack.
    >>
    >>
    >>> That said, I know that in another thread Christer made the point of
    >>> being consistent across the cluster in terms of referencing RFC 5389
    >>> vs. RFC 8489. If the decision is for the cluster switch to RFC 8489,
    >>> we can consider that. However, I think we would need to take it back
    >>> to the working group to see if there are any issues because I do not
    >>> believe the working group was not tracking this update and did not
    >>> anticipate its publication.
    >>
    >>
    >> FWIW, so far, the one C238 document that has updated their STUN
    >> reference to RFC 8489 has an informative ref to it, not a normative one.
    >>
    >> Thanks!
    >>
    >> RFC Editor/jm
    >>
    >>
    >>>
    >>> Cheers,
    >>> Charles
    >>>
    >>> On 5/20/20, 12:36 PM, "Jean Mahoney" <jmahoney@amsl.com<mailto:jmahoney@amsl.com>> wrote:
    >>>
    >>>     Authors,
    >>>
    >>>     We note that this document has a normative reference to RFC 5389
    >>> (STUN),
    >>>     which was obsoleted just recently by RFC 8489.  Do you wish to
    >>> update
    >>>     this reference to RFC 8489?
    >>>
    >>>     Thanks!
    >>>
    >>>     RFC Editor/jm
    >>>
    >>>
    >
    >        _______________________________________________
    >        bfcpbis mailing list
    >        bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>
    >        https://www.ietf.org/mailman/listinfo/bfcpbis
    >
    >
    > _______________________________________________
    > bfcpbis mailing list
    > bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>
    > https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>
https://www.ietf.org/mailman/listinfo/bfcpbis