From nobody Thu Jan 11 01:11:26 2018 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1067D12EAB8 for ; Thu, 11 Jan 2018 01:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4v9IzywBOGgo for ; Thu, 11 Jan 2018 01:11:23 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 E04FF124239 for ; Thu, 11 Jan 2018 01:11:19 -0800 (PST) X-AuditID: c1b4fb3a-716549c0000037f2-1e-5a572a35030f Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 20.79.14322.53A275A5; Thu, 11 Jan 2018 10:11:17 +0100 (CET) Received: from [131.160.50.225] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.352.0; Thu, 11 Jan 2018 10:11:03 +0100 From: Gonzalo Camarillo To: References: <8d5370eb-fdf8-4ce9-7dbb-c27f19967ae2@ericsson.com> Message-ID: Date: Thu, 11 Jan 2018 11:11:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <8d5370eb-fdf8-4ce9-7dbb-c27f19967ae2@ericsson.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM2J7oK6pVniUwdeluhYr1p1icmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpQNl5kLtjNXPL/0jbmB8RpTFyMnh4SAiUTX2y7WLkYuDiGB w4wSF5/vZYNw1jBKdO29xgxSJSxgKzFp1QewDjYBC4ktt+6zgNgiAhISH35fArI5gBrsJfZ0 +IKEeYHM7a8OMYLYLAKqEv8nfmMFsUUFYiQO90xnhagRlDg58wnYGE4BB4m7U2azg4xhFtCU WL9LHyTMLCAucevJfCYIW15i+9s5YNcICWhLLH/WwjKBUWAWkkmzELpnIemehaR7ASPLKkbR 4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAsDy45bfVDsaDzx0PMQpwMCrx8N5TCY8SYk0sK67M PcQowcGsJMK7ODAsSog3JbGyKrUoP76oNCe1+BCjNAeLkjivU5pFlJBAemJJanZqakFqEUyW iYNTqoGRS+CFA1vVVINd/+drVmq/FJyaszdve9CV3QUSrBvP8P082J8na1SqJbovxjHT9ezK P2v+e/zLnNz74r5Rmka3+EZlzblsFhuzk3/xZ72SzjCwuWfHyftplkicdfXjS8fVny2y45oY 8luV4XNIf/bfKyum7dgj95wnw33VwVq3aoWSK7//HtqnxFKckWioxVxUnAgA2qpJJUcCAAA= Archived-At: Subject: Re: [Sipbrandy] WGLC: draft-ietf-sipbrandy-rtpsec-03 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 09:11:25 -0000 Authors of draft-ietf-sipbrandy-rtpsec, this WGLC ends tomorrow. You got a few comments on this list so far. What is your time plan to address them? Cheers, Gonzalo On 12/12/2017 3:46 PM, Gonzalo Camarillo wrote: > Folks, > > I would like to start a WGLC on the following draft. This WGLC will > end on January 12th: > > https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/ > > Thanks, > > Gonzalo > From nobody Thu Jan 11 08:52:57 2018 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E124F12D86E for ; Thu, 11 Jan 2018 08:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar 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 AD-FPZ7DTCvI for ; Thu, 11 Jan 2018 08:52:54 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 EAD9512D7F5 for ; Thu, 11 Jan 2018 08:52:52 -0800 (PST) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0BGh79g023495; Thu, 11 Jan 2018 11:52:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=gaNFRQso7CfJBEUTL/E+ssikxxQGW0XNY4x64uKI3bM=; b=YkHSSIYmQi7ktLIlB45WE2TgGvWrK/5MboL8in0IZcrPIO7q8wr8fU18cQpKtvy4cEuN q1bLYhZTBT7IK3vOwakuYsmCyxSlr7s3tiq4zNFQxabqsj0oSiRDEYi5gccAaV1uDU3l zQR2guGNYI31J8qS+ZAiFltBBC/HyB3tdzeT3/riYwN3Jblco8z+ROqslPCQxSD3/11i fLVl7ZDDgz6XZb07+XdbjPwi/jQvmNnER1+sfZfJ4fk6S4CaL4a3f70ircVMo2a4zR2d CaLuUwTYQkRaL7s+nySDujWyixKnNqtmh1o06epLxByx+KbQNWk2N/HpiuMwerOUDtTs Qg== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2febnug0nf-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jan 2018 11:52:49 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.47]) by stntexhc10.cis.neustar.com ([169.254.4.133]) with mapi id 14.03.0279.002; Thu, 11 Jan 2018 11:52:48 -0500 From: "Peterson, Jon" To: Gonzalo Camarillo , "sipbrandy@ietf.org" Thread-Topic: [Sipbrandy] WGLC: draft-ietf-sipbrandy-rtpsec-03 Thread-Index: AQHTivycTxaQmrhrbEygpflIxnrr7g== Date: Thu, 11 Jan 2018 16:52:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.106] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F6140CF2AA7D54F845A5FAB769E3E0C@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801110231 Archived-At: Subject: Re: [Sipbrandy] WGLC: draft-ietf-sipbrandy-rtpsec-03 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 16:52:56 -0000 Thanks for these notes Gonzalo. A few replies here. > >I have a few initial WGLC comments on this draft. The draft mentions a >few protocols (e.g., SDP) without providing a reference to them. Please, >expand acronyms and add a reference on first use throughout the document. > >In section 3.1, "Real-time Protocol" should be something along the >following lines: "RTP (Real-time Transport Protocol) [RFC3550]". No problem, will expand those. > >Section 3.1 talks about STIR as the "current target mechanism". I would >remove "current", or rephrase it and talk about the mechanism we >recommend to use instead. > >I guess at this point changes in STIR may still trigger modifications in >this draft, right? No, I think (hope) STIR is a stable reference, at this point. > >Section 4 says: > >> The SIPBRANDY deployment profile of STIR >> for media confidentiality thus shifts these responsibilities to the >> endpoints rather than the intermediaries. > >I would rephrase it so that the text is more explicit. If intermediaries >MUST NOT provide the verification service, the text should say so. It's not that they MUST NOT provide it... It's that if they do provide it, it has to be redundant with the endpoint providing it. There are a few potential pitfalls though: if, for example, the verification service does not trust the signing credential but the endpoint does, we wouldn't want an intermediary to drop the call, say. In general, in STIR, we don't encourage that sort of behavior from intermediaries, but, we could certainly clarify all this with a bit of text here. Will add something. > >Section 5 says: > >> In [I-D.johnston-dispatch-osrtp], opportunistic approaches considered >> include DTLS-SRTP, security descriptions [RFC4568], and ZRTP >> [RFC6189]. >> >> DTLS-SRTP is the only Standards Track Internet protocol for media >> security. For that reason, this specification REQUIRES support for >> DTLS-SRTP. > >But RFC 4568 is also Standards Track: > >https://tools.ietf.org/html/rfc4568 The AD responsible for that at the time clearly dropped the ball. But I'll fix the text here, thanks. Jon Peterson Neustar, Inc. > >Cheers, > >Gonzalo > > >On 12/12/2017 3:46 PM, Gonzalo Camarillo wrote: >> Folks, >>=20 >> I would like to start a WGLC on the following draft. This WGLC will >> end on January 12th: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/ >>=20 >> Thanks, >>=20 >> Gonzalo >>=20 > >_______________________________________________ >Sipbrandy mailing list >Sipbrandy@ietf.org >https://www.ietf.org/mailman/listinfo/sipbrandy From nobody Thu Jan 11 09:04:03 2018 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0DF12EBE2 for ; Thu, 11 Jan 2018 09:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar 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 FazwiHU31NlT for ; Thu, 11 Jan 2018 09:03:59 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 C26F912D947 for ; Thu, 11 Jan 2018 09:03:59 -0800 (PST) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0BH3Kkm020690; Thu, 11 Jan 2018 12:03:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=JjgvcZCIeAji4sACEcS++ZN50SL04tg1mpWpqv8JFGM=; b=lhhcZAMYndqEWExWfBXcT5tiAWJjKfcrAXCMDSWOxDO55eCVtyhRigjbRhSJHCKPh9Ph 6BWyZio+yLdi3N2hevnQ13JS0W8Bt2G7NEgiLy/wlyM6f+IyF6+PK0kCU1CxVEvYXAKN gHjcHdDIJLS+dsZujU14FrzKYSXSGeCOIhh5GLHPmr6yaGZ/FM6pDyjZfxF28CkGXwpL 4dQ0EuUmOIUF8m5tBSTM1hVUPJKNfcDmPtbLJ7WEq3dAI/OuKRwpXd0jaexiFZM7yyTf DDiMEes5PyNLS7RQ9PcrFOATORj/6cJkVUiJqJTC3VacJPjQ0F69/2jvQ3ZcCavXkpyF tQ== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2fdabhjxyv-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jan 2018 12:03:57 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.47]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 11 Jan 2018 12:03:56 -0500 From: "Peterson, Jon" To: Russ Housley , "sipbrandy@ietf.org" Thread-Topic: [Sipbrandy] WGLC: draft-ietf-sipbrandy-rtpsec-03 Thread-Index: AQHTiv4pTxaQmrhrbEygpflIxnrr7g== Date: Thu, 11 Jan 2018 17:03:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.106] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801110234 Archived-At: Subject: Re: [Sipbrandy] WGLC: draft-ietf-sipbrandy-rtpsec-03 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 17:04:02 -0000 Thanks for these notes Russ: >Major: > >In Section 4.3, I do not know what is meant by "STIR Profile for media >confidentiality". I think we've been using that language as the name for this entire effort: as a way to leverage STIR through a particular extension with its incumbent behavior to get media confidentiality. Since media confidentiality was definitely not a requirement of STIR initially, this is effectively a profile, a narrow use case applying STIR to something slightly different. I think SHAKEN set the precedent for profiling STIR through an extension, and we are just following that. I'm not sure how to make that more clear, though. > >Minor: > >I think the discussion in the first paragraph of Section 3.1 should be >slightly expanded to be clear that we are not talking about integrity >protection of SDP k=3D records. I'd prefer a MUST NOT statement. Fine by me.=20 > >In Section 4.1: s/SIP endpoints must acquire/SIP endpoints MUST acquire/ So... I don't think this language is stipulating implementation behavior as such - it is expressing a practical necessity rather than something we would test conformance with, I think? The spec then goes on to discuss the actual protocol mechanisms you might use to actually acquire credentials. If the "must" is annoying I can paraphrase to "as a matter of practical necessity need to". Or maybe I need more RFC8174 sensitivity training. > >In Section 4.2:=20 > s/should be discarded/SHOULD be discarded/ > s/should be generated/SHOULD be generated/ These ones however I think you're right, we are talking about implementation behavior. > >Nits: ... Will zap those nits. Thanks! Jon Peterson Neustar, Inc. > > > >> On Dec 12, 2017, at 8:46 AM, Gonzalo Camarillo >> wrote: >>=20 >> Folks, >>=20 >> I would like to start a WGLC on the following draft. This WGLC will >> end on January 12th: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/ >>=20 >> Thanks, >>=20 >> Gonzalo > >_______________________________________________ >Sipbrandy mailing list >Sipbrandy@ietf.org >https://www.ietf.org/mailman/listinfo/sipbrandy From nobody Thu Jan 11 13:07:31 2018 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3E7126B6E for ; Thu, 11 Jan 2018 13:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 99YN0v6Qf-eM for ; Thu, 11 Jan 2018 13:07:29 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F1612D87C for ; Thu, 11 Jan 2018 13:07:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 57A7A3009FC for ; Thu, 11 Jan 2018 16:07:28 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AOGVE3OYwuxP for ; Thu, 11 Jan 2018 16:07:27 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2FD5530056B; Thu, 11 Jan 2018 16:07:27 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Thu, 11 Jan 2018 16:07:26 -0500 Cc: "sipbrandy@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Sipbrandy] WGLC: draft-ietf-sipbrandy-rtpsec-03 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 21:07:31 -0000 > On Jan 11, 2018, at 12:03 PM, Peterson, Jon = wrote: >=20 >=20 > Thanks for these notes Russ: >=20 >> Major: >>=20 >> In Section 4.3, I do not know what is meant by "STIR Profile for = media >> confidentiality". >=20 > I think we've been using that language as the name for this entire = effort: > as a way to leverage STIR through a particular extension with its > incumbent behavior to get media confidentiality. Since media > confidentiality was definitely not a requirement of STIR initially, = this > is effectively a profile, a narrow use case applying STIR to something > slightly different. I think SHAKEN set the precedent for profiling = STIR > through an extension, and we are just following that. I'm not sure how = to > make that more clear, though. I think we need to separate the authentication provided the signature in = STIR and the ability for some other mechanism to leverage that signature = to provide confidentiality. >=20 >>=20 >> Minor: >>=20 >> I think the discussion in the first paragraph of Section 3.1 should = be >> slightly expanded to be clear that we are not talking about integrity >> protection of SDP k=3D records. I'd prefer a MUST NOT statement. >=20 > Fine by me.=20 >=20 >>=20 >> In Section 4.1: s/SIP endpoints must acquire/SIP endpoints MUST = acquire/ >=20 > So... I don't think this language is stipulating implementation = behavior > as such - it is expressing a practical necessity rather than something = we > would test conformance with, I think? The spec then goes on to discuss = the > actual protocol mechanisms you might use to actually acquire = credentials. > If the "must" is annoying I can paraphrase to "as a matter of = practical > necessity need to". Or maybe I need more RFC8174 sensitivity training. That change would help me. >=20 >>=20 >> In Section 4.2:=20 >> s/should be discarded/SHOULD be discarded/ >> s/should be generated/SHOULD be generated/ >=20 > These ones however I think you're right, we are talking about > implementation behavior. Thanks. Russ