Re: [Dime] Dime Errata [Technical Errata Reported] RFC 7155 (6029)

Luke Mewburn <luke@mewburn.net> Sun, 11 February 2024 01:00 UTC

Return-Path: <luke@mewburn.net>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DECC14F5FB for <dime@ietfa.amsl.com>; Sat, 10 Feb 2024 17:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mewburn.net header.b="kPpugCsH"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="ghNurOQj"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44aMrhSCbyYT for <dime@ietfa.amsl.com>; Sat, 10 Feb 2024 17:00:02 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5A0C14F5E5 for <dime@ietf.org>; Sat, 10 Feb 2024 17:00:01 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B1E765C00A1; Sat, 10 Feb 2024 20:00:00 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sat, 10 Feb 2024 20:00:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mewburn.net; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1707613200; x=1707699600; bh=/4HR4zpKym 1rW66bmhPUv1A7rwCAqrb0gZbwrnWWnUo=; b=kPpugCsH4UUC8iIYxHB57CsFcO eZUcrmsycz99P61wEQAUXyao0qzRiIvftHXQFNFIOPsPXDP9wDUPdDHUdbPZBETH UXW27oTwZlI3ORjmfwq7Cd5NHOToX/bViuuUzHrw9FlDb39JZouFWDJ2DAP6Tqvy HTgmSWLdOg5Q8Yu+fu+sGc0wqa9SRPJ9fPlD0be+bZ1SEmopDoASSV31FawwRtJf MrofDrAnFVEAOiRMOcyGwbBpHnzZulOrH07rGTzwx20muZLi7IPcH3D661Db7Ovk 6b17b7SUY9zLpP98bzbpD0DKUkSs7f5/QYVbZ7Znw4WYiGbddo56Dh4XWauQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1707613200; x=1707699600; bh=/4HR4zpKym1rW66bmhPUv1A7rwCA qrb0gZbwrnWWnUo=; b=ghNurOQj6/0R9zApC0YZvt7PlHOdzI2dS8lfs7Xu3AdZ NZpZawpq6eulM2YObYTUwOLp1PXWYzsWlqfys+Dj/xr3h/HwFLS++865lAdEvyT0 UTb+lSMoIbfkpirgXxS4x8I2YYKHvRdCtGdeiPwPZcmWQMdePQQqvw4SximqRvKa byuJydS8FRSBjzcX3K3c/LXe8B2KtZoxzyEsx10nfq4di7WojsEJPLJe2dRTVUmU gopEHhkXdmDgfugxSIoJGWNfeHRv2svyr3hxWgF/1z4EU1XUYyIObopJsp7QtvbC DsUA9LHdxIMPTY3Ryvgam/PKaPjbm5x9rU6yS+sfQA==
X-ME-Sender: <xms:EBzIZSWg3KWeonCw6U7h7J3bZZK5jTnHP6OCvDOiscMZL8d9x5MKqw> <xme:EBzIZemJ49asDQ0zIYBe7qa6rJQpYzS6xUTaI_qTTkxvQdYhsCBHqB1DP34QLgSLU FeSy2nJFCvoXxLeE1A>
X-ME-Received: <xmr:EBzIZWZm9RRzkNrDZ5vIVDyco-GY6K5ZzLoTia7uThgGNh8pMhx8HymMSYRE6e7doayLvZqINaZQLG6e-lk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjffevkfhfvffosegrtdhmrehhtdejnecuhfhrohhmpefnuhhkvgcu ofgvfigsuhhrnhcuoehluhhkvgesmhgvfigsuhhrnhdrnhgvtheqnecuggftrfgrthhtvg hrnhepvdffheffiedtvdeflefhtefhgeeitedvheetueeufeefieekhfdtvedtkeetveek necuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdpihgvthhfrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhhukhgvsehm vgifsghurhhnrdhnvght
X-ME-Proxy: <xmx:EBzIZZWpZ4X3xxZT8VfL64TFqXjMgJXsws7kihSOZ7pJpH7pE4mrOA> <xmx:EBzIZcnWHrd82RvEWY7Lv_vMDIYWJOyvJDwSuSfhPmv6lmKUB6fn7A> <xmx:EBzIZeelTH389B06l14NGplaJz_RvNzuFMAXxD_N1XV52BDSIo7eXQ> <xmx:EBzIZRyUOGE5FnL8pOJnIntYp6K-xPgitXRGFGW3IiszrILjfIx8pw>
Feedback-ID: id591465c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 10 Feb 2024 19:59:59 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C88E77F5-FFA1-4C5E-B91A-44604F68A4D8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
From: Luke Mewburn <luke@mewburn.net>
In-Reply-To: <LV8PR11MB8536C9902A23B7DC524842C9B54B2@LV8PR11MB8536.namprd11.prod.outlook.com>
Date: Sun, 11 Feb 2024 11:59:55 +1100
Cc: "dime@ietf.org" <dime@ietf.org>
Message-Id: <4D213D1B-40F0-4AE4-92A1-A3BD52E0908B@mewburn.net>
References: <LV8PR11MB8536C9902A23B7DC524842C9B54B2@LV8PR11MB8536.namprd11.prod.outlook.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/e--YTLMKwBG1YniYY9U3f08nRm0>
Subject: Re: [Dime] Dime Errata [Technical Errata Reported] RFC 7155 (6029)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Feb 2024 01:00:07 -0000

Hi Rob,

I'm the author of errata 6029.

Summary:

I think the lack of "M" or "V" in QoS-Filter-Rule is an editorial copypasta bug in the original RFC 4005.
"V" flag MUST NOT be used, as QoS-Filter-Rule and all the other RFC 7155 AVPs are base AVPs not vendor AVPs.

Arguably, "M" should have been MUST in the original RFC 4005, but because it wasn't, it may be considered a breaking change to now make "M" MUST for QoS-Filter-Rule. I did highlight this in my note.

As such, I think my errata could be revised to remove "M" from the 'It should say"

Section 4.4 says:

   QoS-Filter-Rule             4.4.9        |    |     |
It should say:

   QoS-Filter-Rule             4.4.9        |    |  V  |

thoughts?



Details:

Spelunking through the Diameter RFCs for QoS related information, I see:


(1). RFC 3588 (obsoleted by RFC 6733) lists AVP Flag Rules in tables with at least 4 columns:
	MUST, MAY, SHLD NOT, MUST NOT
and generally the M, P, and V bits are listed once and once only per AVP.


(2) RFC 6733 (obsoletes RFC 3588) lists AVP Flag Rules in tables with at least 2 columns:
	MUST, MUST NOT
This RFC also changes P bit so that it is reserved, so only M and V are used.


(3) RFC 4005 (obsoleted by RFC 7155) section 6 table contains QoS-Filter-Rule. This does not list any bits for QoS-Filter-Rule in the AVP Flag rules 4 columns  MUST, MAY, SHLD NOT, or MUST NOT. This does not make sense; all of the other AVPs in this RFC list the M, P, and V bits once and once only per row, per (1) above.

I speculate that the reason that QoS-Filter-Rule doesn't have any entries in the table is a copypasta issue from the 2 row Configuration-Token entry above it.


(4) RFC 4005 (obsoleted by RFC 7155) section 6.9 documents QoS-Filter-Rule.
This section states:
	An access device unable to interpret or apply a QoS rule SHOULD NOT
	terminate the session.


(5) RFC 7155 (obsoletes RFC 4005) section 4.1.1 QoSFilterRule,  a derived rule.
This section appears copied from the original RFC 4005 section 6.9 (see (4))


(6). RFC 7155 section 4.4 table lists QoS-Filter-Rule without any AVP Flag Rules.
All other AVPs in this section have the AVP Flag Rules:
	- MUST "M" (Mandatory bit)
	- MUST NOT "V" (Vendor bit) because non of the AVPs in this RFC are vendor AVPs.

This is the errata. I think it is missing "M" and "V" per (3) above.




regards,
Luke.




> On 10 Feb 2024, at 01:39, Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org> wrote:
> 
> Hi Dime WG,
>  
> And another one.  This time, it is errata 6029, https://www.rfc-editor.org/errata/eid6029
>  
> Looking at this RFC and the previous versio, I believe that the table was intentionally defined this way – it seems very unlikely to be a mistake to me, so I would propose rejecting this errata.
> 
> Please reply with any comments by the 16th Feb.
> 
> Regards,
> Rob
>  
>  
> The following errata report has been submitted for RFC7155,
> "Diameter Network Access Server Application".
>  
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6029
>  
> --------------------------------------
> Type: Technical
> Reported by: Luke Mewburn <luke@mewburn.net> <mailto:&lt;luke@mewburn.net&gt;>
>  
> Section: 4.4
>  
> Original Text
> -------------
>    QoS-Filter-Rule             4.4.9        |    |     |
>  
> Corrected Text
> --------------
>    QoS-Filter-Rule             4.4.9        | M  |  V  |
>  
> Notes
> -----
> The row "QoS-Filter-Rule" does not define AVP Flag Rules for "M" or "V":
> - The V Flag MUST NOT be used for this AVP.
> - There may be some debate whether the M Flag can be retrospectively added to the MUST column, versus leaving it out (implied "MAY" ?).
>  
> The changes are consistent with all other AVPs in this RFC.
>  
> 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. 
>  
> --------------------------------------
> RFC7155 (draft-ietf-dime-rfc4005bis-14)
> --------------------------------------
> Title               : Diameter Network Access Server Application
> Publication Date    : April 2014
> Author(s)           : G. Zorn, Ed.
> Category            : PROPOSED STANDARD
> Source              : Diameter Maintenance and Extensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
>  
>  
> _______________________________________________
> DiME mailing list
> DiME@ietf.org <mailto:DiME@ietf.org>
> https://www.ietf.org/mailman/listinfo/dime