From nobody Mon Aug 6 05:01:12 2018 Return-Path: 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 F3D35130DCC for ; Mon, 6 Aug 2018 05:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 mFnk_vlf77x9 for ; Mon, 6 Aug 2018 05:01:08 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41070130934 for ; Mon, 6 Aug 2018 05:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1533556862; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1054; bh=aO54SzLWsVdN95AFwmb9LaOoAlmZOxos3bVD9VBjozs=; b=SD0oQjr3q2GL1AEX2B+u0GezPaL+13ZgRZ3rUZMyWHFvjoVhYk7c42hEBX62GCzn 6HZDVSITf9N/1JieMc/kFZX2f/yHwoU2zU3FPXWmjcEuWLA8rS9GmSY+R6FFyv8xTYc OHImn/AyNjpbPz2DW1qm/jw8hI0+y6D1tmm5rILI= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 15335568619331022.7068283587669; Mon, 6 Aug 2018 05:01:01 -0700 (PDT) Date: Mon, 06 Aug 2018 13:01:01 +0100 From: Denis Ovsienko To: "dime" , "iana" Message-ID: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: [Dime] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 12:01:10 -0000 Hello. Recently I was reviewing some code that adds support for two RFC 5447 RADIUS AVPs below: The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and It turned out, the current RADIUS Types registry at https://www.iana.org/assignments/radius-types/radius-types.xhtml lists both attributes with wrong types: 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] 124 MIP6-Feature-Vector string [RFC5447] Those incorrect types had propagated from the IANA registry into FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home-Link-Prefix, see the discussion and the follow-ups at https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested). Having studied this discrepancy thoroughly, I had concluded the AVP definitions are correct in RFC 5447, so I did not file an erratum. The problem seems to be with those IANA allocations only. Could somebody review this issue and put the IANA allocations right? Thank you. -- Denis Ovsienko From nobody Mon Aug 6 05:59:58 2018 Return-Path: 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 759BC130DDA; Mon, 6 Aug 2018 05:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 QiwS219vY3WX; Mon, 6 Aug 2018 05:59:43 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A4A96130DFD; Mon, 6 Aug 2018 05:59:43 -0700 (PDT) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id 9E8C32C6; Mon, 6 Aug 2018 12:59:41 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Alan DeKok X-Priority: Medium In-Reply-To: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> Date: Mon, 6 Aug 2018 08:59:39 -0400 Cc: dime , iana , radext@ietf.org, Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> To: Denis Ovsienko X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Dime] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 12:59:49 -0000 On Aug 6, 2018, at 8:01 AM, Denis Ovsienko wrote: > Recently I was reviewing some code that adds support for two RFC 5447 = RADIUS AVPs below: >=20 > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and >=20 > It turned out, the current RADIUS Types registry at = https://www.iana.org/assignments/radius-types/radius-types.xhtml lists = both attributes with wrong types: >=20 > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] That is definitely wrong. The "ipv6prefix" format is different than = the one used by MIP6-Home-Link-Prefix in RFC 5337. > 124 MIP6-Feature-Vector string [RFC5447] That issue is a bit different. 64-bit integers were defined in RFC = 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC = 5447 was published. So at the time RFC 5447 was published, "string" was the correct = definition. > Those incorrect types had propagated from the IANA registry into = FreeRADIUS and Wireshark (both have been fixed now for = MIP6-Home-Link-Prefix, see the discussion and the follow-ups at = https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested). >=20 > Having studied this discrepancy thoroughly, I had concluded the AVP = definitions are correct in RFC 5447, so I did not file an erratum. The = problem seems to be with those IANA allocations only. Could somebody = review this issue and put the IANA allocations right? In the end, I think that the incorrect IANA allocations were a result = of the updates done in RFC 8044. The early drafts had a table which = updated all of the IANA data types, e.g.: https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2 The MIP6 attributes are listed there as "ipv6prefix" and "string". As = the author of RFC 8044, I think that's my mistake. Updating hundreds of = attributes required reading many RFCs, and it's understandable that a = few mistakes were made. Unless there are objections from DIME or RADEXT, I think it would be = best for IANA to update the registry as follows: 125 MIP6-Home-Link-Prefix string [RFC5447] 124 MIP6-Feature-Vector integer64 [RFC5447] We may need approval from the AD (Ben). Explicit consensus from the = WG would also be helpful. Alan DeKok. From nobody Mon Aug 6 13:33:38 2018 Return-Path: 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 D8412130E05; Mon, 6 Aug 2018 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 YSN0G5NsEDFx; Mon, 6 Aug 2018 13:33:27 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 83AB6130DCE; Mon, 6 Aug 2018 13:33:27 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id C4C16E0256; Mon, 6 Aug 2018 20:33:26 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 8B829207E6; Mon, 6 Aug 2018 20:33:26 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-matrix@iana.org In-Reply-To: References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1118137 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: kaduk@mit.edu, dime@ietf.org, radext@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 06 Aug 2018 20:33:26 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dime] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 20:33:30 -0000 Hi, On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > wrote: > > Recently I was reviewing some code that adds support for two RFC 5447 > > RADIUS AVPs below: > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and > > > > It turned out, the current RADIUS Types registry at > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > lists both attributes with wrong types: > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > That is definitely wrong. The "ipv6prefix" format is different than > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > 124 MIP6-Feature-Vector string [RFC5447] > > That issue is a bit different. 64-bit integers were defined in RFC > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC > 5447 was published. > > So at the time RFC 5447 was published, "string" was the correct > definition. > > > Those incorrect types had propagated from the IANA registry into > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > Link-Prefix, see the discussion and the follow-ups at > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested). > > > > Having studied this discrepancy thoroughly, I had concluded the AVP > > definitions are correct in RFC 5447, so I did not file an erratum. > > The problem seems to be with those IANA allocations only. Could > > somebody review this issue and put the IANA allocations right? > > In the end, I think that the incorrect IANA allocations were a result > of the updates done in RFC 8044. The early drafts had a table which > updated all of the IANA data types, e.g.: > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2 Right, we took the entries from here when the document was approved: https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section-4.2 > The MIP6 attributes are listed there as "ipv6prefix" and "string". As > the author of RFC 8044, I think that's my mistake. Updating hundreds > of attributes required reading many RFCs, and it's understandable that > a few mistakes were made. > > Unless there are objections from DIME or RADEXT, I think it would be > best for IANA to update the registry as follows: > > 125 MIP6-Home-Link-Prefix string [RFC5447] > 124 MIP6-Feature-Vector integer64 [RFC5447] > > We may need approval from the AD (Ben). Explicit consensus from the > WG would also be helpful. > > Alan DeKok. If there's no errata report required, we can move ahead once the AD lets us know that any appropriate consensus has been reached (if we haven't heard from the chairs first) and gives us the go-ahead. Best regards, Amanda Baber Lead IANA Services Specialist From nobody Tue Aug 7 01:03:32 2018 Return-Path: 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 38313130F59; Tue, 7 Aug 2018 01:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bvCaG5oXbvym; Tue, 7 Aug 2018 01:03:29 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC9D130F5C; Tue, 7 Aug 2018 01:03:28 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 41l6TW27lczFqB4; Tue, 7 Aug 2018 10:03:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 41l6TV6QQdzBrLG; Tue, 7 Aug 2018 10:03:26 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0399.000; Tue, 7 Aug 2018 10:03:26 +0200 From: To: "iana-matrix@iana.org" CC: "radext@ietf.org" , "dime@ietf.org" , "kaduk@mit.edu" Thread-Topic: [radext] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) Thread-Index: AQHULcTBi7dJI32kEUmBqiAVfP2o6aSz7LsA Date: Tue, 7 Aug 2018 08:03:26 +0000 Message-ID: <11227_1533629007_5B69524E_11227_192_1_6B7134B31289DC4FAF731D844122B36E3951AE20@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] [radext] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 08:03:31 -0000 I agree with the proposal. It is important that the types defined in RFC5447 are the ones listed in th= e IANA registry. For information, there are existing implementations relying on these AVPs a= nd it is important to be consistent between the RFC and registry. Regards, Lionel > -----Message d'origine----- > De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Amanda Baber= via > RT > Envoy=E9=A0: lundi 6 ao=FBt 2018 22:33 > Cc=A0: radext@ietf.org; dime@ietf.org; kaduk@mit.edu > Objet=A0: [radext] [IANA #1118137] error in IANA allocations for RFC 5447 > (attributes 124 and 125) >=20 > Hi, >=20 > On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > > wrote: > > > Recently I was reviewing some code that adds support for two RFC 5447 > > > RADIUS AVPs below: > > > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString > > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and > > > > > > It turned out, the current RADIUS Types registry at > > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > > lists both attributes with wrong types: > > > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > > > That is definitely wrong. The "ipv6prefix" format is different than > > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > > > 124 MIP6-Feature-Vector string [RFC5447] > > > > That issue is a bit different. 64-bit integers were defined in RFC > > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC > > 5447 was published. > > > > So at the time RFC 5447 was published, "string" was the correct > > definition. > > > > > Those incorrect types had propagated from the IANA registry into > > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > > Link-Prefix, see the discussion and the follow-ups at > > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested). > > > > > > Having studied this discrepancy thoroughly, I had concluded the AVP > > > definitions are correct in RFC 5447, so I did not file an erratum. > > > The problem seems to be with those IANA allocations only. Could > > > somebody review this issue and put the IANA allocations right? > > > > In the end, I think that the incorrect IANA allocations were a result > > of the updates done in RFC 8044. The early drafts had a table which > > updated all of the IANA data types, e.g.: > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2 >=20 > Right, we took the entries from here when the document was approved: >=20 > https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section-4.2 >=20 > > The MIP6 attributes are listed there as "ipv6prefix" and "string". As > > the author of RFC 8044, I think that's my mistake. Updating hundreds > > of attributes required reading many RFCs, and it's understandable that > > a few mistakes were made. > > > > Unless there are objections from DIME or RADEXT, I think it would be > > best for IANA to update the registry as follows: > > > > 125 MIP6-Home-Link-Prefix string [RFC5447] > > 124 MIP6-Feature-Vector integer64 [RFC5447] > > > > We may need approval from the AD (Ben). Explicit consensus from the > > WG would also be helpful. > > > > Alan DeKok. >=20 > If there's no errata report required, we can move ahead once the AD lets = us > know that any appropriate consensus has been reached (if we haven't heard > from the chairs first) and gives us the go-ahead. >=20 > Best regards, >=20 > Amanda Baber > Lead IANA Services Specialist >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Aug 7 18:59:36 2018 Return-Path: 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 A96C3130DDA; Tue, 7 Aug 2018 18:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 52_t-2vea8Kt; Tue, 7 Aug 2018 18:59:32 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 24E34127332; Tue, 7 Aug 2018 18:59:32 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 46B2DE0158; Wed, 8 Aug 2018 01:59:31 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 0D710207E6; Wed, 8 Aug 2018 01:59:31 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-matrix@iana.org In-Reply-To: References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> <11227_1533629007_5B69524E_11227_192_1_6B7134B31289DC4FAF731D844122B36E3951AE20@OPEXCLILM43.corporate.adroot.infra.ftgroup> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1118137 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: radext@ietf.org, lionel.morand@orange.com, kaduk@mit.edu, dime@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 08 Aug 2018 01:59:31 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dime] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 01:59:35 -0000 Hi Benjamin, Given Lionel's confirmation, should we go ahead and make these changes at https://www.iana.org/assignments/radius-types? OLD: 124 MIP6-Feature-Vector string [RFC5447] 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] NEW: 124 MIP6-Feature-Vector integer64 [RFC5447] 125 MIP6-Home-Link-Prefix string [RFC5447] thanks, Amanda On Tue Aug 07 08:03:49 2018, lionel.morand@orange.com wrote: > I agree with the proposal. > It is important that the types defined in RFC5447 are the ones listed > in the IANA registry. > For information, there are existing implementations relying on these > AVPs and it is important to be consistent between the RFC and > registry. > > Regards, > > Lionel > > > -----Message d'origine----- > > De : radext [mailto:radext-bounces@ietf.org] De la part de Amanda > > Baber via > > RT > > Envoyé : lundi 6 août 2018 22:33 > > Cc : radext@ietf.org; dime@ietf.org; kaduk@mit.edu > > Objet : [radext] [IANA #1118137] error in IANA allocations for RFC > > 5447 > > (attributes 124 and 125) > > > > Hi, > > > > On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > > > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > > > wrote: > > > > Recently I was reviewing some code that adds support for two RFC > > > > 5447 > > > > RADIUS AVPs below: > > > > > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type > > > > OctetString > > > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 > > > > and > > > > > > > > It turned out, the current RADIUS Types registry at > > > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > > > lists both attributes with wrong types: > > > > > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > > > > > That is definitely wrong. The "ipv6prefix" format is different > > > than > > > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > > > > > 124 MIP6-Feature-Vector string [RFC5447] > > > > > > That issue is a bit different. 64-bit integers were defined in RFC > > > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after > > > RFC > > > 5447 was published. > > > > > > So at the time RFC 5447 was published, "string" was the correct > > > definition. > > > > > > > Those incorrect types had propagated from the IANA registry into > > > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > > > Link-Prefix, see the discussion and the follow-ups at > > > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if > > > > interested). > > > > > > > > Having studied this discrepancy thoroughly, I had concluded the > > > > AVP > > > > definitions are correct in RFC 5447, so I did not file an > > > > erratum. > > > > The problem seems to be with those IANA allocations only. Could > > > > somebody review this issue and put the IANA allocations right? > > > > > > In the end, I think that the incorrect IANA allocations were a > > > result > > > of the updates done in RFC 8044. The early drafts had a table > > > which > > > updated all of the IANA data types, e.g.: > > > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section- > > > 4.2 > > > > Right, we took the entries from here when the document was approved: > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section- > > 4.2 > > > > > The MIP6 attributes are listed there as "ipv6prefix" and "string". > > > As > > > the author of RFC 8044, I think that's my mistake. Updating > > > hundreds > > > of attributes required reading many RFCs, and it's understandable > > > that > > > a few mistakes were made. > > > > > > Unless there are objections from DIME or RADEXT, I think it would > > > be > > > best for IANA to update the registry as follows: > > > > > > 125 MIP6-Home-Link-Prefix string [RFC5447] > > > 124 MIP6-Feature-Vector integer64 [RFC5447] > > > > > > We may need approval from the AD (Ben). Explicit consensus from > > > the > > > WG would also be helpful. > > > > > > Alan DeKok. > > > > If there's no errata report required, we can move ahead once the AD > > lets us > > know that any appropriate consensus has been reached (if we haven't > > heard > > from the chairs first) and gives us the go-ahead. > > > > Best regards, > > > > Amanda Baber > > Lead IANA Services Specialist > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. From nobody Fri Aug 10 11:36:22 2018 Return-Path: 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 49EC8130E7D; Fri, 10 Aug 2018 11:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 V2UMb9kwHPU9; Fri, 10 Aug 2018 11:36:13 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 40797130E47; Fri, 10 Aug 2018 11:36:13 -0700 (PDT) X-AuditID: 1209190e-37bff70000001e56-50-5b6ddb1b23eb Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id A2.2A.07766.C1BDD6B5; Fri, 10 Aug 2018 14:36:12 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w7AIa9mr030066; Fri, 10 Aug 2018 14:36:10 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w7AIa4vt019450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2018 14:36:06 -0400 Date: Fri, 10 Aug 2018 13:36:04 -0500 From: Benjamin Kaduk To: Yuval Lifshitz Cc: Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <20180810183601.GR40887@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> <20180524212739.GP32807@kduck.kaduk.org> <502594613.5761891.1527418744898@mail.yahoo.com> <20180529182419.GJ27985@kduck.kaduk.org> <1294588061.6493079.1527620089234@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1294588061.6493079.1527620089234@mail.yahoo.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hTV1pW5nRttcHgWl8X8ztPsFmsPplnM 7V3BZrFk4gRWixl/JjJbHP/2kN2BzWPJkp9MHrN2PmHxmDXrMFMAcxSXTUpqTmZZapG+XQJX xuXdGxkLpnFVPPjwmrWBcTpHFyMnh4SAicT5levZuhi5OIQEFjNJNHS/YYFwNjJKrHj9iBmk SkjgKpPEpU1ACQ4OFgFViQPNYGE2ARWg+stgtoiAmsTjxhtgg5gF+hklrp89D5YQFsiW+DRh AhuIzQu0bf7Fm1ALLjFLnLzzmBEiIShxcuYTFhCbWUBL4sa/l0wgy5gFpCWW/wO7lFPATqJr zzSwmaICyhJ7+w6xT2AUmIWkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpGuvl ZpbopaaUbmIEh7Uk3w7GSQ3ehxgFOBiVeHgvbMyNFmJNLCuuzD3EKMnBpCTK65YNFOJLyk+p zEgszogvKs1JLT7EKMHBrCTCm2kKlONNSaysSi3Kh0lJc7AoifPeqwmPFhJITyxJzU5NLUgt gsnKcHAoSfB+ugnUKFiUmp5akZaZU4KQZuLgBBnOAzR8NkgNb3FBYm5xZjpE/hSjLsef91Mn MQux5OXnpUqJ86bdAioSACnKKM2DmwNKRxLZ+2teMYoDvSXM2w1SxQNMZXCTXgEtYQJakq0J tqQkESEl1cDYUvTlRNqNiw2vxZv0t0YfX3hK641mO+POV0l/fmV2/TjtfKemkDloV/LWdL71 W4+cLEtMLzJ216+x/fuH66oRQ1bkaoOrZi/j+vbsrv1js2rrpY17LvOnLOgu44+fuvf4ndlZ 7B9j3I4L/ztYoHC+NK/Ma8eaYwe7/xW6rWcVkLA9vqj+TTO3EktxRqKhFnNRcSIAnjiajCID AAA= Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 18:36:16 -0000 Hi folks, I finally got a chance to look at the -10; sorry about the delay. Most of the changes look good, but I'm not sure I'm reading things right with respect to my last DISCUSS point. That is, in Section 8.64 (of -10), we still see: The Redirect-Server-Extension AVP (AVP Code TBD13) is of type Grouped and contains the address information of the redirect server (e.g., HTTP redirect server, SIP Server) with which the end user is to be connected when the account cannot cover the service cost. It MUST be present inside the QoS-Final-Unit-Indication AVP when the Final-Unit- Action AVP is set to REDIRECT. That is, Redirect-Server-Extension, specifically, MUST be present in QoS-Final-Unit-Indication when Final-Unit-Action is REDIRECT. Down in Section 8.68, we learn about QoS-Final-Unit-Indication: If the Final-Unit-Action AVP is set to REDIRECT at least one of the Redirect-Server and Redirect-Server-Extension AVPs MUST be present. Maybe I'm just missing part of the nesting structure of the AVPs, but aren't these two statements still in conflict (in that the latter allows sending Redirect-Server without Redirect-Server-Extension, that contradicts the former's MUST requirement)? Thanks for helping me check this, Benjamin From nobody Sat Aug 11 09:07:20 2018 Return-Path: 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 A973D130DD9; Sat, 11 Aug 2018 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SDAYZ0HeKLGO; Sat, 11 Aug 2018 09:07:09 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 558791277C8; Sat, 11 Aug 2018 09:07:09 -0700 (PDT) X-AuditID: 1209190f-f1fff7000000159e-9c-5b6f09aba35b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.30.05534.BA90F6B5; Sat, 11 Aug 2018 12:07:08 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w7BG760f027679; Sat, 11 Aug 2018 12:07:06 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w7BG710w017821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 11 Aug 2018 12:07:04 -0400 Date: Sat, 11 Aug 2018 11:07:01 -0500 From: Benjamin Kaduk To: Amanda Baber via RT Cc: ;, radext@ietf.org, lionel.morand@orange.com, dime@ietf.org Message-ID: <20180811160701.GP40887@kduck.kaduk.org> References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> <11227_1533629007_5B69524E_11227_192_1_6B7134B31289DC4FAF731D844122B36E3951AE20@OPEXCLILM43.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixCmqrbuGMz/a4OwMTou5vSvYLPr2NLBY 3N6eadHyaiabA4tHj7zHkiU/mTxanp1kC2CO4rJJSc3JLEst0rdL4MpYNH8eY8Fb/Yqv766z NDDeVeli5OSQEDCRmPzyLmMXIxeHkMBiJokDh6czgySEBDYySvRPzoRIXGWSuPXsMhtIgkVA VWLxnG4WEJtNQEWiofsyWIOIgJ7EipalTCA2s4C9xNLNp1lBbGGBOIn537exg9i8QNsmrnjN CrHgLLPEq7klEHFBiZMzn7BA9OpI7Nx6B2gXB5AtLbH8HwdEWF6ieetssFWcAo4Sbx98ABsp KqAssbfvEPsERsFZSCbNQjJpFsKkWUgmLWBkWcUom5JbpZubmJlTnJqsW5ycmJeXWqRropeb WaKXmlK6iREc7JL8OxjnNHgfYhTgYFTi4b2wMTdaiDWxrLgy9xCjJAeTkiiv2Ny8aCG+pPyU yozE4oz4otKc1OJDjBIczEoivGffA+V4UxIrq1KL8mFS0hwsSuK892rCo4UE0hNLUrNTUwtS i2CyMhwcShK80zjyo4UEi1LTUyvSMnNKENJMHJwgw3mAhpeB1PAWFyTmFmemQ+RPMdpzvFjU M4mZ48JjEDnv6FQg+ec9kBRiycvPS5US520AaRMAacsozYObDEpkEtn7a14xigM9Ksy7BqSK B5gE4Wa/AlrLBLQ2WzMXZG1JIkJKqoFxmez13xUik276vkhb2Deh6PXet7YuP+MLdBoT5RUs TjEuPrHsvqJgzC4tmTuOCj6/jq2ZdTjD+c8+Jt0d9f4nXvbc36p+YPPBs28lPs1rXr13pauh 6GMNKfFj7jenJnpevBz9+OvnW3vn5dstqi2e+udMZi/PngPpMiwsjPf/SumbJ8/+xZP0RIml OCPRUIu5qDgRABDiffU/AwAA Archived-At: Subject: Re: [Dime] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 16:07:12 -0000 Hi Amanda, On Wed, Aug 08, 2018 at 01:59:31AM +0000, Amanda Baber via RT wrote: > Hi Benjamin, > > Given Lionel's confirmation, should we go ahead and make these changes at https://www.iana.org/assignments/radius-types? Yes, please make those changes. Thanks, Benjamin > OLD: > > 124 MIP6-Feature-Vector string [RFC5447] > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > NEW: > > 124 MIP6-Feature-Vector integer64 [RFC5447] > 125 MIP6-Home-Link-Prefix string [RFC5447] > > thanks, > Amanda > > On Tue Aug 07 08:03:49 2018, lionel.morand@orange.com wrote: > > I agree with the proposal. > > It is important that the types defined in RFC5447 are the ones listed > > in the IANA registry. > > For information, there are existing implementations relying on these > > AVPs and it is important to be consistent between the RFC and > > registry. > > > > Regards, > > > > Lionel > > > > > -----Message d'origine----- > > > De: radext [mailto:radext-bounces@ietf.org] De la part de Amanda > > > Baber via > > > RT > > > Envoy: lundi 6 aot 2018 22:33 > > > Cc: radext@ietf.org; dime@ietf.org; kaduk@mit.edu > > > Objet: [radext] [IANA #1118137] error in IANA allocations for RFC > > > 5447 > > > (attributes 124 and 125) > > > > > > Hi, > > > > > > On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > > > > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > > > > wrote: > > > > > Recently I was reviewing some code that adds support for two RFC > > > > > 5447 > > > > > RADIUS AVPs below: > > > > > > > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type > > > > > OctetString > > > > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 > > > > > and > > > > > > > > > > It turned out, the current RADIUS Types registry at > > > > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > > > > lists both attributes with wrong types: > > > > > > > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > > > > > > > That is definitely wrong. The "ipv6prefix" format is different > > > > than > > > > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > > > > > > > 124 MIP6-Feature-Vector string [RFC5447] > > > > > > > > That issue is a bit different. 64-bit integers were defined in RFC > > > > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after > > > > RFC > > > > 5447 was published. > > > > > > > > So at the time RFC 5447 was published, "string" was the correct > > > > definition. > > > > > > > > > Those incorrect types had propagated from the IANA registry into > > > > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > > > > Link-Prefix, see the discussion and the follow-ups at > > > > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if > > > > > interested). > > > > > > > > > > Having studied this discrepancy thoroughly, I had concluded the > > > > > AVP > > > > > definitions are correct in RFC 5447, so I did not file an > > > > > erratum. > > > > > The problem seems to be with those IANA allocations only. Could > > > > > somebody review this issue and put the IANA allocations right? > > > > > > > > In the end, I think that the incorrect IANA allocations were a > > > > result > > > > of the updates done in RFC 8044. The early drafts had a table > > > > which > > > > updated all of the IANA data types, e.g.: > > > > > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section- > > > > 4.2 > > > > > > Right, we took the entries from here when the document was approved: > > > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section- > > > 4.2 > > > > > > > The MIP6 attributes are listed there as "ipv6prefix" and "string". > > > > As > > > > the author of RFC 8044, I think that's my mistake. Updating > > > > hundreds > > > > of attributes required reading many RFCs, and it's understandable > > > > that > > > > a few mistakes were made. > > > > > > > > Unless there are objections from DIME or RADEXT, I think it would > > > > be > > > > best for IANA to update the registry as follows: > > > > > > > > 125 MIP6-Home-Link-Prefix string [RFC5447] > > > > 124 MIP6-Feature-Vector integer64 [RFC5447] > > > > > > > > We may need approval from the AD (Ben). Explicit consensus from > > > > the > > > > WG would also be helpful. > > > > > > > > Alan DeKok. > > > > > > If there's no errata report required, we can move ahead once the AD > > > lets us > > > know that any appropriate consensus has been reached (if we haven't > > > heard > > > from the chairs first) and gives us the go-ahead. > > > > > > Best regards, > > > > > > Amanda Baber > > > Lead IANA Services Specialist > > > > > > _______________________________________________ > > > radext mailing list > > > radext@ietf.org > > > https://www.ietf.org/mailman/listinfo/radext > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > > been modified, changed or falsified. > > Thank you. > From nobody Sun Aug 12 07:15:56 2018 Return-Path: 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 66165130DE8 for ; Sun, 12 Aug 2018 07:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 3zg4va0tcojc for ; Sun, 12 Aug 2018 07:15:53 -0700 (PDT) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24E2130934 for ; Sun, 12 Aug 2018 07:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1534083351; bh=TSjGg3rb3bIVP7Md6f17A0+WmMmgyrTK62zngtHHdXY=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=cLRnKuCvmg3BMrJF64SurbHtYM2QaZQ4I++N9dp8WDJDd4XoKyLBZGN4R60VovUN4YNAVEdtR/3zYk4T4aRycRzDOdiWHa/dCHYcO50Pxdi1YoLP0OOeE7uveOaWRwbsbjsJ+A4NRrTJpNcZQQJbCFTec0qQr4c6c9xFRofn+W5JSoBnDmTVocCGkUR6DmeZsIg27Kod1dymuvIOoHkc+APfMf1Q9f2vW+5L9EwCHliHrbH3awjINtG6tu1AgP0y1+9DLz9znGzDQ5ubwZKus3eQiMqNXQr2S1cDxblNDT/8MlFpnJyzR2o04lNNvi643Diol3632aDQP8a2jxGL5A== X-YMail-OSG: fMavsvcVM1nNdhd_huUaHQoeuw57wff1NOMkYZvTdNS9MhdAy1srUZrNR7Okuda 0v.fRkeZBWyQOIwI8p9z.js5kMnRUTuZ6MixP25maCCTr5gXvBDzNes.37OQwm2Spr_h6.IXvcXx mJlX4ftxbskZwjXFtlR15Lbhsm_sDDn4SK1mVxwbCFeplE5O0gJWpZGOrMWnJI5kj_h.0fHiQXIi AQCHaQvOg4MM1IaM8uS8OhPHCft6gxl4e_q8_jNWktuc1BYl8Y5FqTNZ7uA5LXjzoDy4NU95zOwy Oglh8CTloUOdoVRJzQKdiAjG_ckICwNgJ83DhAlXGjo8sSjJotFq.7IzGcoEagL1dE8CuXCm0jtT zEvKc3WfUTQzKQmJ4gvRe0SnZGDr_R6hjJwRjJbTpUKFbeQrYqI56kOu38GhqwpkA2_D0TW.4xyF OJr5Ryp6qBb1XqOQHZLXTUps4PmhG8gDefMYbvBQQzFMDYZ1rdFvjqQNTFDLh4ult3SPuQoFWd5D qQ5TdjXh6ApDolVNlpaaY2jcx2RxVkCeNQix9njR9J3N_XfL7XDWsr70DZTpyHHMsjAn7DnsZExw RnaeQZcze8VhJuNk0lgv1k.rsrK4CEzhTtqHM2oZ6Jh0eQTRDTvc.pEcuw2qPYCEYQIuGyPL3dgu WAz4Bn9BkqVjww3jIAuUxna47MXwBe9dVwcMgJZmZa.cYYF2L0UUxebkx1gtWlgHtc9TQw1Vt0HY _Rp38unHh9Zx.Z7xNqMhcZA2wnNq0UA6R7AxQOsGS0DGwlUfAefzRnF.0y4UjUCpNr0PVF5PJsz2 yd6YGMf4oXgHjiODqPyHIotCSBc1fhduvcvkBf3NPqIsJJ90MfV10AZhSpE0V4xNMXi9jZUe4opb oht.I4vWAloKZuifnRkAsHsVaK2.kA.XJR09rMxtV0GYgHKmnd_p51nYWAFpEHQawTQEZLNZKql1 6.Kb2xPpkrpGX3DJnCGEka6DcLQvSsTk.3ITuJOg6iQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Sun, 12 Aug 2018 14:15:51 +0000 Date: Sun, 12 Aug 2018 14:05:46 +0000 (UTC) From: Yuval Lifshitz To: Benjamin Kaduk Cc: Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <1627146293.6117198.1534082746577@mail.yahoo.com> In-Reply-To: <20180810183601.GR40887@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> <20180524212739.GP32807@kduck.kaduk.org> <502594613.5761891.1527418744898@mail.yahoo.com> <20180529182419.GJ27985@kduck.kaduk.org> <1294588061.6493079.1527620089234@mail.yahoo.com> <20180810183601.GR40887@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6117197_555436264.1534082746575" X-Mailer: WebService/1.1.12206 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 14:15:54 -0000 ------=_Part_6117197_555436264.1534082746575 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Benjamin,You are correct, this is a copy&paste error from "Final-Unit-I= ndication" AVP (which may contain both types). If someone is using the newl= y introduced "QoS-Final-Unit-Indication" AVP, they should only be allowed t= o use the new "Redirect-Server-Extension" AVP in it.Should fix to:"If the F= inal-Unit-Action AVP is set to REDIRECT then the Redirect-Server-Extension = AVPs MUST be present." Yuval On Friday, August 10, 2018, 9:36:13 p.m. GMT+3, Benjamin Kaduk wrote: =20 =20 Hi folks, I finally got a chance to look at the -10; sorry about the delay. Most of the changes look good, but I'm not sure I'm reading things right with respect to my last DISCUSS point.=C2=A0 That is, in Section 8.64 (of -= 10), we still see: =C2=A0 The Redirect-Server-Extension AVP (AVP Code TBD13) is of type Groupe= d =C2=A0 and contains the address information of the redirect server (e.g., =C2=A0 HTTP redirect server, SIP Server) with which the end user is to be =C2=A0 connected when the account cannot cover the service cost.=C2=A0 It M= UST be =C2=A0 present inside the QoS-Final-Unit-Indication AVP when the Final-Unit= - =C2=A0 Action AVP is set to REDIRECT. That is, Redirect-Server-Extension, specifically, MUST be present in QoS-Final-Unit-Indication when Final-Unit-Action is REDIRECT. Down in Section 8.68, we learn about QoS-Final-Unit-Indication: =C2=A0 If the Final-Unit-Action AVP is set to REDIRECT at least one of the =C2=A0 Redirect-Server and Redirect-Server-Extension AVPs MUST be present. Maybe I'm just missing part of the nesting structure of the AVPs, but aren't these two statements still in conflict (in that the latter allows sending Redirect-Server without Redirect-Server-Extension, that contradicts the former's MUST requirement)? Thanks for helping me check this, Benjamin =20 ------=_Part_6117197_555436264.1534082746575 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benjamin,
You are correct, this is a copy&pas= te error from "Final-Unit-Indication" AVP (which may contain both typ= es). If someone is using the newly introduced "QoS-Final-Unit-Indicat= ion" AVP, they should only be allowed to use the new "Redirect-Server= -Extension" AVP in it.
Should fix to:<= /span>
"
If the Final-Uni= t-Action AVP is set to REDIRECT then the Redirect-Server-Extension AVPs MUS= T be present.
"

Yuval

=20
=20
On Friday, August 10, 2018, 9:36:13 p.m. GMT+3, Benjami= n Kaduk <kaduk@mit.edu> wrote:


Hi folks,

I final= ly got a chance to look at the -10; sorry about the delay.

Most of the changes look good, but I'm not sure I'm re= ading things right
with respect to my last DISCUSS point.=   That is, in Section 8.64 (of -10),
we still see:
  The Redirect-Server-Extension A= VP (AVP Code TBD13) is of type Grouped
  and contai= ns the address information of the redirect server (e.g.,
=   HTTP redirect server, SIP Server) with which the end user is to be<= br clear=3D"none">  connected when the account cannot cover the servi= ce cost.  It MUST be
  present inside the QoS-= Final-Unit-Indication AVP when the Final-Unit-
  Ac= tion AVP is set to REDIRECT.

That is, = Redirect-Server-Extension, specifically, MUST be present in
QoS-Final-Unit-Indication when Final-Unit-Action is REDIRECT.

Down in Section 8.68, we learn about QoS-Final= -Unit-Indication:

  If the Final= -Unit-Action AVP is set to REDIRECT at least one of the
&= nbsp; Redirect-Server and Redirect-Server-Extension AVPs MUST be present.<= br clear=3D"none">
Maybe I'm just missing part of the nes= ting structure of the AVPs, but
aren't these two statemen= ts still in conflict (in that the latter allows
sending R= edirect-Server without Redirect-Server-Extension, that contradicts
the former's MUST requirement)?

Thanks for helping me check this,


Benjamin
<= /div>
------=_Part_6117197_555436264.1534082746575-- From nobody Mon Aug 13 14:11:41 2018 Return-Path: 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 BC3A1130E3A for ; Mon, 13 Aug 2018 14:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 T0jKleAQf9QU for ; Mon, 13 Aug 2018 14:11:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A841310BF for ; Mon, 13 Aug 2018 14:11:36 -0700 (PDT) Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7DLAvVm068296 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Aug 2018 16:10:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_690C6A4D-74F6-47C1-BC53-297EB1B9874F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 13 Aug 2018 16:10:56 -0500 In-Reply-To: <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net> Cc: Suresh Krishnan , The IESG , Jouni Korhonen , dime@ietf.org, dime-chairs@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org To: Dave Dolson References: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 21:11:39 -0000 --Apple-Mail=_690C6A4D-74F6-47C1-BC53-297EB1B9874F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I don=E2=80=99t think Suresh=E2=80=99s DISCUSS has been resolved in = revision 10.Please see inline: Thanks! Ben. > On May 23, 2018, at 9:03 PM, Dave Dolson wrote: >=20 > Suresh, >=20 > Please see inline. >=20 >=20 > On 2018-05-23 04:55 PM, Suresh Krishnan wrote: >> Suresh Krishnan has entered the following ballot position for >> draft-ietf-dime-rfc4006bis-08: Discuss >>=20 >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Section 8.38. >>=20 >> RFC5952 contains significant changes in text representation from = RFC3513 and I >> am concerned that there might be RFC4006 compliant implementations = that will no >> longer be legal with a MUST level use of RFC5952. e.g. Addresses with = upper >> case hex digits, with leading zeroes in 16 bit fields etc. Has the = working >> group considered this break in compatibility already in its = discussions? >>=20 >> If it has, this text should still be finessed a bit because RFC5952 >> recommendations (even at the MUST level) are a SHOULD for senders = with the >> receivers being required to handle all possible legal formats as per = RFC4291. >> So at least the sender rules and receiver rules need to be written = differently. > If I recall correctly, we did give this some thought. RFC 5952 was = presumably done for a reason, due to flaws in previous descriptions of = address format. Hence it is prudent to use the new requirements. = Implementations are free to be liberal in what they receive, for = backwards compatibility with RFC 4006. > So I think it's fair to say this standard requires use of RFC 5952 = syntax. I cannot find evidence of discussion on the DIME list about backwards = compatibility related to the RFC 5952 encoding. Authors/Shepherd: Are you aware of something I missed? Maybe this was = discussed in a meeting? Does anyone know whether existing = implementations are typically compatible with 5952? (I guess this is = most commonly used in 3GPP networks; does anyone know if the relevant = 3GPP specs have anything to say bout 5952 vs 3513 encoding?) In any case, this doesn=E2=80=99t respond to Suresh=E2=80=99s second = paragraph, and I don=E2=80=99t find changes in version 10 related to it. I think that to clear Suresh=E2=80=99s DISCUSS, the draft needs to at = least include a short discussion of the potential for backwards = compatibility issues, and to clarify the normative language around as = described in his second paragraph. Suresh: Do you agree? >=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Section 8.65 >>=20 >> Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped = IPv6 >> Address while you can directly use address family 1 to encode it = directly as an >> IPv4 address? This allows for two different encodings for the same = address. > Because IPv4-mapped IPv6 is a good idea. It allows coders to ignore = IPv4 and just develop for IPv6. > If we hadn't mentioned it explicitly, I think some people would have = assumed it to be supported and others not. > So we had the choice of allowing it or prohibiting it. We chose to = allow. >=20 >=20 > -Dave >=20 --Apple-Mail=_690C6A4D-74F6-47C1-BC53-297EB1B9874F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAltx8+AACgkQgFZKbJXz 1A2i1g/6A3DitYcZkvDdGS80/PDlpOqfHVAObkADo0ML2efj29xDyQ6YGsaxpxTe eEUIc3Gvse+oBRbEbRG1N4flDkpbaCemZlZni2PFEZZvyOTfLBatYqFDh8IcTS1o ZXjCE9XDAhbxD2VMRAFLFJCzWgZTKyUCr7IAQQ/ZudCOWGGQHEhcA+/PcJGjSUpP SHJl8/xzIhcN2QeNYWSSIlsLz+cLei/cY1D13By3CVoeQA6Il5amE+BpKctnltS4 23am1KtngQunTngPWQQKndvBJ9U8jSI6t2nF0YLZ7BPoYnF7P9nFERi7GCwOxKe8 rqA1/a1IwmOYGkKm2XUhDvrJw4Vxq7Q6tOZBSElKHH0AUH9+S+BsBOxTAfljZMwW KYdoDJv0o0c81JeN0Uk+DOHtz9IZmX7B07wG8Vgz3I6XSSZk/Y9NwzzeuZqGOkuv JQeL0//E5eYv/KsEEo/62k/smkuXxDRdjqNT/Sd5lDLwgxzYpRNbH2OdCmr3UE3m UJu5dDdWEkAhtsUSxTKKzYdtC5evU3AfmGRuGPeQdu0spGSr873hiRAjTYKhG2nZ K0+FoVLMJxBkBEJkopave+npaAVZXND5m2GMjs+JECEpik8LzmYAyWOsQys242yx bJOXLe0D7ahPlAmfoy1s/Ihdc7/wzMINQzHrwqv1JNzTLoUU8Cg= =DUgE -----END PGP SIGNATURE----- --Apple-Mail=_690C6A4D-74F6-47C1-BC53-297EB1B9874F-- From nobody Mon Aug 13 14:28:51 2018 Return-Path: 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 5CF1C1310DC for ; Mon, 13 Aug 2018 14:28:50 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=ovsienko.info 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 etz_sFdWuXlQ for ; Mon, 13 Aug 2018 14:28:49 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D9813102C for ; Mon, 13 Aug 2018 14:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1534195728; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=736; bh=Gd49HTIxLiIROPYu9uIquS60SnEVKK/e4Zagvu5GoIw=; b=bVahSy5H5w2G37Y8Bm93uqvjXPKgaeUYMrhXAySONmQwaOHhavlitEKHO3RCNRti a6tiAZvEVj/bSvzLRFSNtRmCmjz80dnSguuP1+ntGDGnBijr0A408W3mbFgkXpinhN/ +RKZ+WsskEZeqG6x2Gzo/bmWRK1NZLX/3csKfPj8= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1534195726477421.3541318617969; Mon, 13 Aug 2018 14:28:46 -0700 (PDT) Date: Mon, 13 Aug 2018 22:28:46 +0100 From: Denis Ovsienko To: "Alan DeKok" , "dime" Message-ID: <1653530f88b.ddb4852f136444.182877631447793885@ovsienko.info> In-Reply-To: References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [Dime] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 21:28:50 -0000 ---- On Mon, 06 Aug 2018 13:59:39 +0100 Alan DeKok wrote ---- [...] > In the end, I think that the incorrect IANA allocations were a result of the updates done in RFC 8044. The early drafts had a table which updated all of the IANA data types, e.g.: > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2 > > The MIP6 attributes are listed there as "ipv6prefix" and "string". As the author of RFC 8044, I think that's my mistake. Updating hundreds of attributes required reading many RFCs, and it's understandable that a few mistakes were made. [...] Everybody makes mistakes. Not everybody has the capability to admit and put it right. Well done. -- Denis Ovsienko From nobody Mon Aug 13 15:35:09 2018 Return-Path: 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 9A82E1310EE; Mon, 13 Aug 2018 15:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 sJlT-NnrT4bW; Mon, 13 Aug 2018 15:35:05 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 2FEE81310D8; Mon, 13 Aug 2018 15:35:05 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 77B39E0445; Mon, 13 Aug 2018 22:35:04 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 39A2020705; Mon, 13 Aug 2018 22:35:04 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-matrix@iana.org In-Reply-To: References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1118137 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: radext@ietf.org, lionel.morand@orange.com, kaduk@mit.edu, dime@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 13 Aug 2018 22:35:04 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dime] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 22:35:08 -0000 Hi all, These RADIUS Attribute Type registrations now read as follows: Value: 124 Description: MIP6-Feature-Vector Data Type: integer64 Reference: [RFC5447] Value: 125 Description: MIP6-Home-Link-Prefix Data Type: string Reference: [RFC5447] Please see https://www.iana.org/assignments/radius-types These updates were made after we received confirmation from Lionel Morand and Benjamin Kaduk. Best regards, Amanda Baber Lead IANA Services Specialist On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > wrote: > > Recently I was reviewing some code that adds support for two RFC 5447 > > RADIUS AVPs below: > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and > > > > It turned out, the current RADIUS Types registry at > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > lists both attributes with wrong types: > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > That is definitely wrong. The "ipv6prefix" format is different than > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > 124 MIP6-Feature-Vector string [RFC5447] > > That issue is a bit different. 64-bit integers were defined in RFC > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC > 5447 was published. > > So at the time RFC 5447 was published, "string" was the correct > definition. > > > Those incorrect types had propagated from the IANA registry into > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > Link-Prefix, see the discussion and the follow-ups at > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested). > > > > Having studied this discrepancy thoroughly, I had concluded the AVP > > definitions are correct in RFC 5447, so I did not file an erratum. > > The problem seems to be with those IANA allocations only. Could > > somebody review this issue and put the IANA allocations right? > > In the end, I think that the incorrect IANA allocations were a result > of the updates done in RFC 8044. The early drafts had a table which > updated all of the IANA data types, e.g.: > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2 > > The MIP6 attributes are listed there as "ipv6prefix" and "string". As > the author of RFC 8044, I think that's my mistake. Updating hundreds > of attributes required reading many RFCs, and it's understandable that > a few mistakes were made. > > Unless there are objections from DIME or RADEXT, I think it would be > best for IANA to update the registry as follows: > > 125 MIP6-Home-Link-Prefix string [RFC5447] > 124 MIP6-Feature-Vector integer64 [RFC5447] > > We may need approval from the AD (Ben). Explicit consensus from the > WG would also be helpful. > > Alan DeKok. From nobody Wed Aug 15 08:44:57 2018 Return-Path: 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 806A2131064; Wed, 15 Aug 2018 08:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 3Ya4Ks0-7b0O; Wed, 15 Aug 2018 08:44:51 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED52131067; Wed, 15 Aug 2018 08:44:51 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id d70-v6so17715352ith.1; Wed, 15 Aug 2018 08:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dmc4ZbkWg9r2AMDRHbOXWPTOVwYT2zD5jxybx8N+9Ug=; b=ULLIgWcO5k4cvFY7yF5OxQgX7FzO33XbDEAExXmtRzSW19jrmaS+fARfjJlbiqx0yb SfhFMsXrZi1iqcCg8Xgu+08BeXL00Lvd/TCZp49MXgIORHWhKQ7H6ZpuVh26PtYAywyO wpYpjqXir4jGdY2wNtSroJubBTyy06Dl1eHhJmxYKtIPdQJ3BRpkOiYLXi3qug2f+9EC gr7XajZ1e2pKUorAdoyVr5GTiMZXa3Slq3X3fT5PucprKepAC7OOrGAE7RZQdt+Ohgu0 Btpp9PXZvkE2JhgONcnPWDSMeItCF5DOs/1keB5ZjyG4S52ir/80N7mrGpO7UnyxIgGl inNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dmc4ZbkWg9r2AMDRHbOXWPTOVwYT2zD5jxybx8N+9Ug=; b=i8/aDqZYvmwxIKaDwhKceIpyqgnjypPmj7+VoYfOCScTx1fkWjZ3cH9Dde0NHtJOjj Q/qzR6D1+G1hT5JT4oYN9ZYSaws+cE5M24esqvEuoHQaiZkfq70XZ+JXN8ZFdD8bnwyJ pk+tl84dhFEQVqiEBlkpXyow5uPaI5SZMtPe+sspLNM4k5qBAQC5x8vWv8mv9WqNF0LE epHFcGgpjL7DYLM7HJ8UelcHDpjS2E3VVRkyhlneXXj2r1RX2vHQoz4qC+b3RTfcKuHO TxWGIuj+ptK5ebHYxYiAnKlHtV/H48egeE+97BhANUB9VzFQyMI3ehLqmiQnmBFTLEd6 zblA== X-Gm-Message-State: AOUpUlGRVDtgAHbKVmlVeKG3ynckl8E07XoHKRqp4vzxzK+YThs71q1m jLggqYYXN607IG7bZJHdfng= X-Google-Smtp-Source: AA+uWPy0CApSVmecdxIps/Kj0H0qnxeELW9CJ0PsRJoWNwfIvXo8HMWj/azect+zNMzBwGrhRiauAw== X-Received: by 2002:a02:7610:: with SMTP id z16-v6mr23672604jab.145.1534347890866; Wed, 15 Aug 2018 08:44:50 -0700 (PDT) Received: from [10.0.0.15] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id m7-v6sm9191648iog.30.2018.08.15.08.44.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 08:44:49 -0700 (PDT) From: Suresh Krishnan Message-Id: <5BCB718E-29E6-401C-9AF0-55AEE6435159@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D9F11FDD-0CCD-4A6F-9C91-73A4C8646FD5" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 15 Aug 2018 11:44:48 -0400 In-Reply-To: Cc: Dave Dolson , Jouni Korhonen , draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG To: Ben Campbell References: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 15:44:55 -0000 --Apple-Mail=_D9F11FDD-0CCD-4A6F-9C91-73A4C8646FD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, > On Aug 13, 2018, at 5:10 PM, Ben Campbell > wrote: >=20 > Hi, >=20 > I don=E2=80=99t think Suresh=E2=80=99s DISCUSS has been resolved in = revision 10.Please see inline: >=20 > Thanks! >=20 > Ben. >=20 >> On May 23, 2018, at 9:03 PM, Dave Dolson > wrote: >>=20 >> Suresh, >>=20 >> Please see inline. >>=20 >>=20 >> On 2018-05-23 04:55 PM, Suresh Krishnan wrote: >>> Suresh Krishnan has entered the following ballot position for >>> draft-ietf-dime-rfc4006bis-08: Discuss >>>=20 >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ = >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> Section 8.38. >>>=20 >>> RFC5952 contains significant changes in text representation from = RFC3513 and I >>> am concerned that there might be RFC4006 compliant implementations = that will no >>> longer be legal with a MUST level use of RFC5952. e.g. Addresses = with upper >>> case hex digits, with leading zeroes in 16 bit fields etc. Has the = working >>> group considered this break in compatibility already in its = discussions? >>>=20 >>> If it has, this text should still be finessed a bit because RFC5952 >>> recommendations (even at the MUST level) are a SHOULD for senders = with the >>> receivers being required to handle all possible legal formats as per = RFC4291. >>> So at least the sender rules and receiver rules need to be written = differently. >> If I recall correctly, we did give this some thought. RFC 5952 was = presumably done for a reason, due to flaws in previous descriptions of = address format. Hence it is prudent to use the new requirements. = Implementations are free to be liberal in what they receive, for = backwards compatibility with RFC 4006. >> So I think it's fair to say this standard requires use of RFC 5952 = syntax. >=20 > I cannot find evidence of discussion on the DIME list about backwards = compatibility related to the RFC 5952 encoding. >=20 > Authors/Shepherd: Are you aware of something I missed? Maybe this was = discussed in a meeting? Does anyone know whether existing = implementations are typically compatible with 5952? (I guess this is = most commonly used in 3GPP networks; does anyone know if the relevant = 3GPP specs have anything to say bout 5952 vs 3513 encoding?) >=20 > In any case, this doesn=E2=80=99t respond to Suresh=E2=80=99s second = paragraph, and I don=E2=80=99t find changes in version 10 related to it. >=20 > I think that to clear Suresh=E2=80=99s DISCUSS, the draft needs to at = least include a short discussion of the potential for backwards = compatibility issues, and to clarify the normative language around as = described in his second paragraph. >=20 > Suresh: Do you agree? Yes. I agree. I am fine even if the text simply says some legacy = implementations may no longer be compliant because of this change. Thanks Suresh --Apple-Mail=_D9F11FDD-0CCD-4A6F-9C91-73A4C8646FD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Ben,


On Aug 13, 2018, at 5:10 PM, = Ben Campbell <ben@nostrum.com> wrote:

Hi,

I don=E2=80=99t think Suresh=E2=80= =99s DISCUSS has been resolved in revision 10.Please see = inline:

Thanks!

Ben.

On May 23, 2018, at 9:03 PM, Dave = Dolson <ddolson@golden.net> wrote:

Suresh,

Please see inline.


On 2018-05-23 04:55 PM, Suresh = Krishnan wrote:
Suresh = Krishnan has entered the following ballot position for
draft-ietf-dime-rfc4006bis-08: Discuss



Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Section 8.38.

RFC5952 contains significant changes in text representation = from RFC3513 and I
am concerned that there might be = RFC4006 compliant implementations that will no
longer be = legal with a MUST level use of RFC5952. e.g. Addresses with upper
case hex digits, with leading zeroes in 16 bit fields etc. = Has the working
group considered this break in = compatibility already in its discussions?

If = it has, this text should still be finessed a bit because RFC5952
recommendations (even at the MUST level) are a SHOULD for = senders with the
receivers being required to handle all = possible legal formats as per RFC4291.
So at least the = sender rules and receiver rules need to be written differently.
If I recall correctly, we did give this some = thought. RFC 5952 was presumably done for a reason, due to flaws in = previous descriptions of address format. Hence it is prudent to use the = new requirements. Implementations are free to be liberal in what they = receive, for backwards compatibility with RFC 4006.
So I = think it's fair to say this standard requires use of RFC 5952 syntax.

I cannot find evidence of discussion on the DIME list about = backwards compatibility related to the RFC 5952 encoding.

Authors/Shepherd: Are you aware = of something I missed? Maybe this was discussed in a meeting? Does = anyone know whether existing implementations are typically compatible = with 5952? (I guess this is most commonly used in 3GPP networks; does = anyone know if the relevant 3GPP specs have anything to say bout 5952 vs = 3513 encoding?)

In any case, this doesn=E2=80=99t respond to Suresh=E2=80=99s = second paragraph, and I don=E2=80=99t find changes in version 10 related = to it.

I think that = to clear Suresh=E2=80=99s DISCUSS, the draft needs to at least include a = short discussion of the potential for backwards compatibility issues, = and to clarify the normative language around as described in his second = paragraph.

Suresh: Do = you agree?

Yes. I agree. I am fine even if the text simply says = some legacy implementations may no longer be compliant because of this = change.

Thanks
Suresh

= --Apple-Mail=_D9F11FDD-0CCD-4A6F-9C91-73A4C8646FD5-- From nobody Mon Aug 20 06:23:50 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B929F126F72; Mon, 20 Aug 2018 06:23:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153477142875.23147.7756795074760914915.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2018 06:23:48 -0700 Archived-At: Subject: [Dime] Alissa Cooper's No Objection on draft-ietf-dime-rfc4006bis-10: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 13:23:49 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dime-rfc4006bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. Original COMMENT: = Section 1 = (1) I know it's a term of art, but the term "next generation wireless networks" seems a bit out of place in two ways: (1) "wireless" seems more generic than what is implied (i.e., "cellular," I assume), and (2) is Rel-13 considered "next generation" still? (2) "Diameter base protocol" should cite RFC 6733. = Section 5.1 = Assuming G-S-U stands for granted service unit, the acronym should be given upon first use here. = Section 8.52 = (1) Why do you need to specify the ability to send either the IMEISV or the IMEI? (2) "If the type of the equipment is one of the enumerated types of User-Equipment-Info-Type AVP, then the credit- control client SHOULD send the information in the User-Equipment-Info AVP, in addition to or instead of the User-Equipment-Info-Extension AVP." Why is this normative recommendation in support of backwards compatibility different from the one given for the Subscription-Id-Extension AVP in Sec. 8.58? = Section 15.1 = "Redirect-Server-Address AVP: the service-provider may embed personal information on the subscriber in the URL/I (e.g. to create a personalized message)." This seems like a bad idea that, if it's going to be mentioned, should be recommended against. From nobody Tue Aug 21 18:31:43 2018 Return-Path: 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 65EA2128C65; Tue, 21 Aug 2018 18:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 7kTH3BqzK8qk; Tue, 21 Aug 2018 18:31:39 -0700 (PDT) Received: from smtp1.execulink.net (smtp1.execulink.net [69.63.44.82]) (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 25F111277CC; Tue, 21 Aug 2018 18:31:38 -0700 (PDT) Received: from mtprnf0117w-156-57-107-107.dhcp-dynamic.fibreop.nl.bellaliant.net ([156.57.107.107] helo=[192.168.2.24]) by smtp1.execulink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1fsHzl-0006rM-Cq; Tue, 21 Aug 2018 21:31:37 -0400 To: Suresh Krishnan , Ben Campbell Cc: Jouni Korhonen , draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG References: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net> <5BCB718E-29E6-401C-9AF0-55AEE6435159@gmail.com> From: Dave Dolson Message-ID: <42a2c82f-2401-1774-97ee-071b11b9e58c@golden.net> Date: Tue, 21 Aug 2018 23:01:33 -0230 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5BCB718E-29E6-401C-9AF0-55AEE6435159@gmail.com> Content-Type: multipart/alternative; boundary="------------B066BC50CA9A5163B58413F0" Content-Language: en-US Archived-At: Subject: Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 01:31:42 -0000 This is a multi-part message in MIME format. --------------B066BC50CA9A5163B58413F0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Would a backwards compatibility statement go in section 8.38 itself, or in the appendix C (Changes relative to RFC4006)? I suggest that in section 8.38, the following paragraph be added: "Because RFC5952 is more restrictive than the RFC3513 format required by RFC4006, implementations receiving this AVP MAY be liberal in the textual IPv6 representations that are accepted without raising an error." Comments? -Dave On 2018-08-15 1:14 PM, Suresh Krishnan wrote: > Hi Ben, > > >> On Aug 13, 2018, at 5:10 PM, Ben Campbell > > wrote: >> >> Hi, >> >> I don’t think Suresh’s DISCUSS has been resolved in revision >> 10.Please see inline: >> >> Thanks! >> >> Ben. >> >>> On May 23, 2018, at 9:03 PM, Dave Dolson >> > wrote: >>> >>> Suresh, >>> >>> Please see inline. >>> >>> >>> On 2018-05-23 04:55 PM, Suresh Krishnan wrote: >>>> Suresh Krishnan has entered the following ballot position for >>>> draft-ietf-dime-rfc4006bis-08: Discuss >>>> >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> Section 8.38. >>>> >>>> RFC5952 contains significant changes in text representation from >>>> RFC3513 and I >>>> am concerned that there might be RFC4006 compliant implementations >>>> that will no >>>> longer be legal with a MUST level use of RFC5952. e.g. Addresses >>>> with upper >>>> case hex digits, with leading zeroes in 16 bit fields etc. Has the >>>> working >>>> group considered this break in compatibility already in its >>>> discussions? >>>> >>>> If it has, this text should still be finessed a bit because RFC5952 >>>> recommendations (even at the MUST level) are a SHOULD for senders >>>> with the >>>> receivers being required to handle all possible legal formats as >>>> per RFC4291. >>>> So at least the sender rules and receiver rules need to be written >>>> differently. >>> If I recall correctly, we did give this some thought. RFC 5952 was >>> presumably done for a reason, due to flaws in previous descriptions >>> of address format. Hence it is prudent to use the new requirements. >>> Implementations are free to be liberal in what they receive, for >>> backwards compatibility with RFC 4006. >>> So I think it's fair to say this standard requires use of RFC 5952 >>> syntax. >> >> I cannot find evidence of discussion on the DIME list about backwards >> compatibility related to the RFC 5952 encoding. >> >> Authors/Shepherd: Are you aware of something I missed? Maybe this was >> discussed in a meeting? Does anyone know whether existing >> implementations are typically compatible with 5952? (I guess this is >> most commonly used in 3GPP networks; does anyone know if the relevant >> 3GPP specs have anything to say bout 5952 vs 3513 encoding?) >> >> In any case, this doesn’t respond to Suresh’s second paragraph, and I >> don’t find changes in version 10 related to it. >> >> I think that to clear Suresh’s DISCUSS, the draft needs to at least >> include a short discussion of the potential for backwards >> compatibility issues, and to clarify the normative language around as >> described in his second paragraph. >> >> Suresh: Do you agree? > > Yes. I agree. I am fine even if the text simply says some legacy > implementations may no longer be compliant because of this change. > > Thanks > Suresh > --------------B066BC50CA9A5163B58413F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Would a backwards compatibility statement go in section 8.38 itself, or in the appendix C (Changes relative to RFC4006)?

I suggest that in section 8.38, the following paragraph be added:

"Because RFC5952 is more restrictive than the RFC3513 format required by RFC4006, implementations receiving this AVP MAY be liberal in the textual IPv6 representations that are accepted without raising an error."

Comments?

-Dave


On 2018-08-15 1:14 PM, Suresh Krishnan wrote:
Hi Ben,



Hi,

I don’t think Suresh’s DISCUSS has been resolved in revision 10.Please see inline:

Thanks!

Ben.

On May 23, 2018, at 9:03 PM, Dave Dolson <ddolson@golden.net> wrote:

Suresh,

Please see inline.


On 2018-05-23 04:55 PM, Suresh Krishnan wrote:
Suresh Krishnan has entered the following ballot position for
draft-ietf-dime-rfc4006bis-08: Discuss



Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 8.38.

RFC5952 contains significant changes in text representation from RFC3513 and I
am concerned that there might be RFC4006 compliant implementations that will no
longer be legal with a MUST level use of RFC5952. e.g. Addresses with upper
case hex digits, with leading zeroes in 16 bit fields etc. Has the working
group considered this break in compatibility already in its discussions?

If it has, this text should still be finessed a bit because RFC5952
recommendations (even at the MUST level) are a SHOULD for senders with the
receivers being required to handle all possible legal formats as per RFC4291.
So at least the sender rules and receiver rules need to be written differently.
If I recall correctly, we did give this some thought. RFC 5952 was presumably done for a reason, due to flaws in previous descriptions of address format. Hence it is prudent to use the new requirements. Implementations are free to be liberal in what they receive, for backwards compatibility with RFC 4006.
So I think it's fair to say this standard requires use of RFC 5952 syntax.

I cannot find evidence of discussion on the DIME list about backwards compatibility related to the RFC 5952 encoding.

Authors/Shepherd: Are you aware of something I missed? Maybe this was discussed in a meeting? Does anyone know whether existing implementations are typically compatible with 5952? (I guess this is most commonly used in 3GPP networks; does anyone know if the relevant 3GPP specs have anything to say bout 5952 vs 3513 encoding?)

In any case, this doesn’t respond to Suresh’s second paragraph, and I don’t find changes in version 10 related to it.

I think that to clear Suresh’s DISCUSS, the draft needs to at least include a short discussion of the potential for backwards compatibility issues, and to clarify the normative language around as described in his second paragraph.

Suresh: Do you agree?

Yes. I agree. I am fine even if the text simply says some legacy implementations may no longer be compliant because of this change.

Thanks
Suresh


--------------B066BC50CA9A5163B58413F0-- From nobody Wed Aug 22 15:18:13 2018 Return-Path: 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 CE7CD130E46; Wed, 22 Aug 2018 15:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 IgTOL6XZZAwp; Wed, 22 Aug 2018 15:18:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB9A124C04; Wed, 22 Aug 2018 15:18:04 -0700 (PDT) Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7MMHoEG021835 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Aug 2018 17:17:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <760D014C-05DC-461F-AFE4-38FE5FD694D1@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B9867B76-E1B9-488F-868D-1A57EF626EDA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 22 Aug 2018 17:17:49 -0500 In-Reply-To: <42a2c82f-2401-1774-97ee-071b11b9e58c@golden.net> Cc: Suresh Krishnan , Jouni Korhonen , draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG To: Dave Dolson References: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net> <5BCB718E-29E6-401C-9AF0-55AEE6435159@gmail.com> <42a2c82f-2401-1774-97ee-071b11b9e58c@golden.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 22:18:06 -0000 --Apple-Mail=_B9867B76-E1B9-488F-868D-1A57EF626EDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I agree this should go in 8.38, not in the appendix. Would something to the effect of the following make sense? "Because RFC5952 is more restrictive than the RFC3513 format required by = RFC4006, some legacy implementations may not be compliant with the new = requirements. Accordingly, implementations receiving this AVP MAY be = liberal in the textual IPv6 representations that are accepted without = raising an error.=E2=80=9D Thanks! Ben. > On Aug 21, 2018, at 8:31 PM, Dave Dolson wrote: >=20 > Would a backwards compatibility statement go in section 8.38 itself, = or in the appendix C (Changes relative to RFC4006)? >=20 > I suggest that in section 8.38, the following paragraph be added: >=20 > "Because RFC5952 is more restrictive than the RFC3513 format required = by RFC4006, implementations receiving this AVP MAY be liberal in the = textual IPv6 representations that are accepted without raising an = error." >=20 > Comments? > -Dave >=20 > On 2018-08-15 1:14 PM, Suresh Krishnan wrote: >> Hi Ben, >>=20 >>=20 >>> On Aug 13, 2018, at 5:10 PM, Ben Campbell wrote: >>>=20 >>> Hi, >>>=20 >>> I don=E2=80=99t think Suresh=E2=80=99s DISCUSS has been resolved in = revision 10.Please see inline: >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>>> On May 23, 2018, at 9:03 PM, Dave Dolson = wrote: >>>>=20 >>>> Suresh, >>>>=20 >>>> Please see inline. >>>>=20 >>>>=20 >>>> On 2018-05-23 04:55 PM, Suresh Krishnan wrote: >>>>> Suresh Krishnan has entered the following ballot position for >>>>> draft-ietf-dime-rfc4006bis-08: Discuss >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found = here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> Section 8.38. >>>>>=20 >>>>> RFC5952 contains significant changes in text representation from = RFC3513 and I >>>>> am concerned that there might be RFC4006 compliant implementations = that will no >>>>> longer be legal with a MUST level use of RFC5952. e.g. Addresses = with upper >>>>> case hex digits, with leading zeroes in 16 bit fields etc. Has the = working >>>>> group considered this break in compatibility already in its = discussions? >>>>>=20 >>>>> If it has, this text should still be finessed a bit because = RFC5952 >>>>> recommendations (even at the MUST level) are a SHOULD for senders = with the >>>>> receivers being required to handle all possible legal formats as = per RFC4291. >>>>> So at least the sender rules and receiver rules need to be written = differently. >>>> If I recall correctly, we did give this some thought. RFC 5952 was = presumably done for a reason, due to flaws in previous descriptions of = address format. Hence it is prudent to use the new requirements. = Implementations are free to be liberal in what they receive, for = backwards compatibility with RFC 4006. >>>> So I think it's fair to say this standard requires use of RFC 5952 = syntax. >>>=20 >>> I cannot find evidence of discussion on the DIME list about = backwards compatibility related to the RFC 5952 encoding. >>>=20 >>> Authors/Shepherd: Are you aware of something I missed? Maybe this = was discussed in a meeting? Does anyone know whether existing = implementations are typically compatible with 5952? (I guess this is = most commonly used in 3GPP networks; does anyone know if the relevant = 3GPP specs have anything to say bout 5952 vs 3513 encoding?) >>>=20 >>> In any case, this doesn=E2=80=99t respond to Suresh=E2=80=99s second = paragraph, and I don=E2=80=99t find changes in version 10 related to it. >>>=20 >>> I think that to clear Suresh=E2=80=99s DISCUSS, the draft needs to = at least include a short discussion of the potential for backwards = compatibility issues, and to clarify the normative language around as = described in his second paragraph. >>>=20 >>> Suresh: Do you agree? >>=20 >> Yes. I agree. I am fine even if the text simply says some legacy = implementations may no longer be compliant because of this change. >>=20 >> Thanks >> Suresh >>=20 >=20 --Apple-Mail=_B9867B76-E1B9-488F-868D-1A57EF626EDA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlt94Q0ACgkQgFZKbJXz 1A0qFBAAx1Dy+1afr4OB1w/xPC5Oo804fLeBRd1dALABd79odYAZVXsh0P1SesiV YMC6mG+LqH2U39jgc7BrIFOFD4aIAI8Q39yJNRDM8O7dR8yyf0TzJnrCLuyIFxuy CHdM5BhsTctad8pxpIPv9oNkURbTwiVhVnNBaQRtFP/gY3a7Wrc1a9yKFtXGzhNW 8uRM4nEJGKZGVyzw2L7Je8ufDRDxe8aUceEYBZsQ5odfXDe2Q08urvyftcFHI/xL mM4W4DtPyK8UcJPVOzBBYxYnkjPYb7tCcGfM0oRscRLF7V6pvf+DQiru5IadQIMi il6sIsSzh5jiFlJvDE8S2OYBYl7Mt/gQF1x3z8/AqgMgFsgvXT59f2p7ltGa6XP3 GeJn2leVPXLX4/aTG0T91LHRdED0bmvAHX0s8HnWBAr/o0qGIB5dlGKojiHcS6Ai ixY1/EAyLAIu1aXY+3plUItjkT1GL8T/MPjaNOqhT/8FzF4UQw4T6OZvN0KJ7wBC 92DLW8OI5fCat0fN/8RDycX4dHNP9Ynemn796gkVKAV0hWs1EJbwXAj6v3Uf3QBB kcOv+vIDY/DUx6npKNmbun15s8pNbuHULoVoTpxLnbgCZvsrrJYTL01/qcp/AUln GNmJgTJQXPyxXKvNiKMxVnTWx0l5OH/GVqedTqttm/rAhA0wWvw= =WGnj -----END PGP SIGNATURE----- --Apple-Mail=_B9867B76-E1B9-488F-868D-1A57EF626EDA-- From nobody Wed Aug 22 17:38:34 2018 Return-Path: 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 00B17130E52 for ; Wed, 22 Aug 2018 17:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Pp11KY_sgiRj for ; Wed, 22 Aug 2018 17:38:30 -0700 (PDT) Received: from smtp1.execulink.net (smtp1.execulink.net [69.63.44.82]) (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 A1A2512F18C for ; Wed, 22 Aug 2018 17:38:30 -0700 (PDT) Received: from mtprnf0117w-156-57-107-107.dhcp-dynamic.fibreop.nl.bellaliant.net ([156.57.107.107] helo=[192.168.2.24]) by smtp1.execulink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1fsdds-0004bg-Pg for dime@ietf.org; Wed, 22 Aug 2018 20:38:29 -0400 To: dime@ietf.org References: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net> <5BCB718E-29E6-401C-9AF0-55AEE6435159@gmail.com> <42a2c82f-2401-1774-97ee-071b11b9e58c@golden.net> <760D014C-05DC-461F-AFE4-38FE5FD694D1@nostrum.com> From: Dave Dolson Message-ID: <107e5421-10a5-4e5f-f82b-dfa799d4b131@golden.net> Date: Wed, 22 Aug 2018 22:08:24 -0230 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <760D014C-05DC-461F-AFE4-38FE5FD694D1@nostrum.com> Content-Type: multipart/alternative; boundary="------------92849B275E5D0D57358EBFA2" Content-Language: en-US Archived-At: Subject: Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 00:38:33 -0000 This is a multi-part message in MIME format. --------------92849B275E5D0D57358EBFA2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sure, that's even more explicit. Any objections? On 2018-08-22 7:47 PM, Ben Campbell wrote: > Hi, > > I agree this should go in 8.38, not in the appendix. > > Would something to the effect of the following make sense? > > "Because RFC5952 is more restrictive than the RFC3513 format required by RFC4006, some legacy implementations may not be compliant with the new requirements. Accordingly, implementations receiving this AVP MAY be liberal in the textual IPv6 representations that are accepted without raising an error.” > > Thanks! > > Ben. > >> On Aug 21, 2018, at 8:31 PM, Dave Dolson wrote: >> >> Would a backwards compatibility statement go in section 8.38 itself, or in the appendix C (Changes relative to RFC4006)? >> >> I suggest that in section 8.38, the following paragraph be added: >> >> "Because RFC5952 is more restrictive than the RFC3513 format required by RFC4006, implementations receiving this AVP MAY be liberal in the textual IPv6 representations that are accepted without raising an error." >> >> Comments? >> -Dave >> >> On 2018-08-15 1:14 PM, Suresh Krishnan wrote: >>> Hi Ben, >>> >>> >>>> On Aug 13, 2018, at 5:10 PM, Ben Campbell wrote: >>>> >>>> Hi, >>>> >>>> I don’t think Suresh’s DISCUSS has been resolved in revision 10.Please see inline: >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>>> On May 23, 2018, at 9:03 PM, Dave Dolson wrote: >>>>> >>>>> Suresh, >>>>> >>>>> Please see inline. >>>>> >>>>> >>>>> On 2018-05-23 04:55 PM, Suresh Krishnan wrote: >>>>>> Suresh Krishnan has entered the following ballot position for >>>>>> draft-ietf-dime-rfc4006bis-08: Discuss >>>>>> >>>>>> >>>>>> >>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> Section 8.38. >>>>>> >>>>>> RFC5952 contains significant changes in text representation from RFC3513 and I >>>>>> am concerned that there might be RFC4006 compliant implementations that will no >>>>>> longer be legal with a MUST level use of RFC5952. e.g. Addresses with upper >>>>>> case hex digits, with leading zeroes in 16 bit fields etc. Has the working >>>>>> group considered this break in compatibility already in its discussions? >>>>>> >>>>>> If it has, this text should still be finessed a bit because RFC5952 >>>>>> recommendations (even at the MUST level) are a SHOULD for senders with the >>>>>> receivers being required to handle all possible legal formats as per RFC4291. >>>>>> So at least the sender rules and receiver rules need to be written differently. >>>>> If I recall correctly, we did give this some thought. RFC 5952 was presumably done for a reason, due to flaws in previous descriptions of address format. Hence it is prudent to use the new requirements. Implementations are free to be liberal in what they receive, for backwards compatibility with RFC 4006. >>>>> So I think it's fair to say this standard requires use of RFC 5952 syntax. >>>> I cannot find evidence of discussion on the DIME list about backwards compatibility related to the RFC 5952 encoding. >>>> >>>> Authors/Shepherd: Are you aware of something I missed? Maybe this was discussed in a meeting? Does anyone know whether existing implementations are typically compatible with 5952? (I guess this is most commonly used in 3GPP networks; does anyone know if the relevant 3GPP specs have anything to say bout 5952 vs 3513 encoding?) >>>> >>>> In any case, this doesn’t respond to Suresh’s second paragraph, and I don’t find changes in version 10 related to it. >>>> >>>> I think that to clear Suresh’s DISCUSS, the draft needs to at least include a short discussion of the potential for backwards compatibility issues, and to clarify the normative language around as described in his second paragraph. >>>> >>>> Suresh: Do you agree? >>> Yes. I agree. I am fine even if the text simply says some legacy implementations may no longer be compliant because of this change. >>> >>> Thanks >>> Suresh >>> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------92849B275E5D0D57358EBFA2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Sure, that's even more explicit. Any objections?


On 2018-08-22 7:47 PM, Ben Campbell wrote:
Hi,

I agree this should go in 8.38, not in the appendix.

Would something to the effect of the following make sense?

"Because RFC5952 is more restrictive than the RFC3513 format required by RFC4006, some legacy implementations may not be compliant with the new requirements. Accordingly, implementations receiving this AVP MAY be liberal in the textual IPv6 representations that are accepted without raising an error.”

Thanks!

Ben.


On Aug 21, 2018, at 8:31 PM, Dave Dolson <ddolson@acm.org> wrote:

Would a backwards compatibility statement go in section 8.38 itself, or in the appendix C (Changes relative to RFC4006)?

I suggest that in section 8.38, the following paragraph be added:

"Because RFC5952 is more restrictive than the RFC3513 format required by RFC4006, implementations receiving this AVP MAY be liberal in the textual IPv6 representations that are accepted without raising an error."

Comments?
-Dave

On 2018-08-15 1:14 PM, Suresh Krishnan wrote:

Hi Ben,



On Aug 13, 2018, at 5:10 PM, Ben Campbell <ben@nostrum.com> wrote:

Hi,

I don’t think Suresh’s DISCUSS has been resolved in revision 10.Please see inline:

Thanks!

Ben.


On May 23, 2018, at 9:03 PM, Dave Dolson <ddolson@golden.net> wrote:

Suresh,

Please see inline.


On 2018-05-23 04:55 PM, Suresh Krishnan wrote:

Suresh Krishnan has entered the following ballot position for
draft-ietf-dime-rfc4006bis-08: Discuss



Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 8.38.

RFC5952 contains significant changes in text representation from RFC3513 and I
am concerned that there might be RFC4006 compliant implementations that will no
longer be legal with a MUST level use of RFC5952. e.g. Addresses with upper
case hex digits, with leading zeroes in 16 bit fields etc. Has the working
group considered this break in compatibility already in its discussions?

If it has, this text should still be finessed a bit because RFC5952
recommendations (even at the MUST level) are a SHOULD for senders with the
receivers being required to handle all possible legal formats as per RFC4291.
So at least the sender rules and receiver rules need to be written differently.

If I recall correctly, we did give this some thought. RFC 5952 was presumably done for a reason, due to flaws in previous descriptions of address format. Hence it is prudent to use the new requirements. Implementations are free to be liberal in what they receive, for backwards compatibility with RFC 4006.
So I think it's fair to say this standard requires use of RFC 5952 syntax.

I cannot find evidence of discussion on the DIME list about backwards compatibility related to the RFC 5952 encoding.

Authors/Shepherd: Are you aware of something I missed? Maybe this was discussed in a meeting? Does anyone know whether existing implementations are typically compatible with 5952? (I guess this is most commonly used in 3GPP networks; does anyone know if the relevant 3GPP specs have anything to say bout 5952 vs 3513 encoding?)

In any case, this doesn’t respond to Suresh’s second paragraph, and I don’t find changes in version 10 related to it.

I think that to clear Suresh’s DISCUSS, the draft needs to at least include a short discussion of the potential for backwards compatibility issues, and to clarify the normative language around as described in his second paragraph.

Suresh: Do you agree?

Yes. I agree. I am fine even if the text simply says some legacy implementations may no longer be compliant because of this change.

Thanks
Suresh



      

      

      

      

      

      
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


    

    

  


--------------92849B275E5D0D57358EBFA2--


From nobody Thu Aug 23 13:38:43 2018
Return-Path: 
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 B5669130EFE; Thu, 23 Aug 2018 13:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 VNWmg7QfSx1s; Thu, 23 Aug 2018 13:38:33 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B866130F02; Thu, 23 Aug 2018 13:38:33 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id v66-v6so3208525pgb.10; Thu, 23 Aug 2018 13:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=m5E5GHN5buu5TB33McS7968Tztpz4aQ2S6/TCU2EI6U=; b=l5vDfdxa+uKD3YX4I/+Q6oDOfH0241pYxtxlpxCmb4W2FcCuPiBGAKFYeK3V6VCnvk 6TRC96wpSEp76stwDmBNh4+pRX6TvBvZ3+SY9GonV9dTzeSsPhPo1OOmHlhLx+qW0q6L qyNPfinUakypJtTlYON5QR2hvasIRuqCDoxjTpRb5Ngcpw9e04houhPH0A9x5faAa4i2 Aqb1UV+Z9jAX2XbBS2EIvSl9iO3GPWaAi9/AGdIfSCPCOc/b+GR+WhZGcSIxfs6VqGrz /pkEuR7LvBfOkWsNovUT1IXY06SpjApN2AJ566nw00LXzdWK2YgDMctHC2ugCNqz0PV2 4aVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=m5E5GHN5buu5TB33McS7968Tztpz4aQ2S6/TCU2EI6U=; b=okP8ThamNeTEs/EhG4xJlHZUCDpp0HzXJr3NlodkU9ak+4dRw5IA7A6kb0hnj4txGy HA6gvjrh5Qmr9CJE5hhXqr2Wep2B9ANbp0WnHwoffp50rQ0MeSCmB04/B+4VR9Do+aP5 frhXJmgIqYWe3bK/gJ08T2AxJN4Stnzn1n29HePOrZv1vDlGVOLSqWC+MAmg/8KY7pfG cjyc+C95Uxasji2Jwh9RUlk77FEXHxppylvXCNrw30YWTDIvC7Ol55AvCgVz69gT0P7j 2X4piuCXxbfYqg+OQFxTTHN60/vtVgynlc1rp2GuqCbDV4MIwL18y4VRtPb1NtLwAa7s iBCQ==
X-Gm-Message-State: AOUpUlH+Bq7hXFB8JIfBYCSuRGRwQbVurHJaQJ30+WkB4yasqM+DpNJk WjbwY4cKzPt8AoJ3EzZjN2MuaIc2/Ec9fYm2999Phw==
X-Google-Smtp-Source: AA+uWPysqxQGFo+eg0b96czt/TZyMyr7z5EdBVlCMCCYa33QfrqUI3onWifFamsti+rGy3el2ctuyt7qUVCMSokY+Oc=
X-Received: by 2002:a63:fa49:: with SMTP id g9-v6mr56718431pgk.18.1535056712929;  Thu, 23 Aug 2018 13:38:32 -0700 (PDT)
MIME-Version: 1.0
References: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net>  <5BCB718E-29E6-401C-9AF0-55AEE6435159@gmail.com> <42a2c82f-2401-1774-97ee-071b11b9e58c@golden.net> <760D014C-05DC-461F-AFE4-38FE5FD694D1@nostrum.com>
In-Reply-To: <760D014C-05DC-461F-AFE4-38FE5FD694D1@nostrum.com>
From: Suresh Krishnan 
Date: Thu, 23 Aug 2018 16:38:21 -0400
Message-ID: 
To: Ben Campbell 
Cc: ddolson@acm.org, "jouni. nospam" ,  draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org,  IESG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Aug 2018 20:38:36 -0000

Hi Dave/Ben,
  This new text suggestion fully addresses my DISCUSS. I will clear as
soon as the new version hits (or if Ben can add an RFC editor note, I
will clear right away).

Regards
Suresh
On Wed, Aug 22, 2018 at 6:17 PM Ben Campbell  wrote:
>
> Hi,
>
> I agree this should go in 8.38, not in the appendix.
>
> Would something to the effect of the following make sense?
>
> "Because RFC5952 is more restrictive than the RFC3513 format required by =
RFC4006, some legacy implementations may not be compliant with the new requ=
irements. Accordingly, implementations receiving this AVP MAY be liberal in=
 the textual IPv6 representations that are accepted without raising an erro=
r.=E2=80=9D
>
> Thanks!
>
> Ben.
>
> > On Aug 21, 2018, at 8:31 PM, Dave Dolson  wrote:
> >
> > Would a backwards compatibility statement go in section 8.38 itself, or=
 in the appendix C (Changes relative to RFC4006)?
> >
> > I suggest that in section 8.38, the following paragraph be added:
> >
> > "Because RFC5952 is more restrictive than the RFC3513 format required b=
y RFC4006, implementations receiving this AVP MAY be liberal in the textual=
 IPv6 representations that are accepted without raising an error."
> >
> > Comments?
> > -Dave
> >
> > On 2018-08-15 1:14 PM, Suresh Krishnan wrote:
> >> Hi Ben,
> >>
> >>
> >>> On Aug 13, 2018, at 5:10 PM, Ben Campbell  wrote:
> >>>
> >>> Hi,
> >>>
> >>> I don=E2=80=99t think Suresh=E2=80=99s DISCUSS has been resolved in r=
evision 10.Please see inline:
> >>>
> >>> Thanks!
> >>>
> >>> Ben.
> >>>
> >>>> On May 23, 2018, at 9:03 PM, Dave Dolson  wrote:
> >>>>
> >>>> Suresh,
> >>>>
> >>>> Please see inline.
> >>>>
> >>>>
> >>>> On 2018-05-23 04:55 PM, Suresh Krishnan wrote:
> >>>>> Suresh Krishnan has entered the following ballot position for
> >>>>> draft-ietf-dime-rfc4006bis-08: Discuss
> >>>>>
> >>>>>
> >>>>>
> >>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteri=
a.html
> >>>>> for more information about IESG DISCUSS and COMMENT positions.
> >>>>>
> >>>>>
> >>>>> The document, along with other ballot positions, can be found here:
> >>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/
> >>>>>
> >>>>>
> >>>>>
> >>>>> -------------------------------------------------------------------=
---
> >>>>> DISCUSS:
> >>>>> -------------------------------------------------------------------=
---
> >>>>>
> >>>>> Section 8.38.
> >>>>>
> >>>>> RFC5952 contains significant changes in text representation from RF=
C3513 and I
> >>>>> am concerned that there might be RFC4006 compliant implementations =
that will no
> >>>>> longer be legal with a MUST level use of RFC5952. e.g. Addresses wi=
th upper
> >>>>> case hex digits, with leading zeroes in 16 bit fields etc. Has the =
working
> >>>>> group considered this break in compatibility already in its discuss=
ions?
> >>>>>
> >>>>> If it has, this text should still be finessed a bit because RFC5952
> >>>>> recommendations (even at the MUST level) are a SHOULD for senders w=
ith the
> >>>>> receivers being required to handle all possible legal formats as pe=
r RFC4291.
> >>>>> So at least the sender rules and receiver rules need to be written =
differently.
> >>>> If I recall correctly, we did give this some thought. RFC 5952 was p=
resumably done for a reason, due to flaws in previous descriptions of addre=
ss format. Hence it is prudent to use the new requirements. Implementations=
 are free to be liberal in what they receive, for backwards compatibility w=
ith RFC 4006.
> >>>> So I think it's fair to say this standard requires use of RFC 5952 s=
yntax.
> >>>
> >>> I cannot find evidence of discussion on the DIME list about backwards=
 compatibility related to the RFC 5952 encoding.
> >>>
> >>> Authors/Shepherd: Are you aware of something I missed? Maybe this was=
 discussed in a meeting? Does anyone know whether existing implementations =
are typically compatible with 5952? (I guess this is most commonly used in =
3GPP networks; does anyone know if the relevant 3GPP specs have anything to=
 say bout 5952 vs 3513 encoding?)
> >>>
> >>> In any case, this doesn=E2=80=99t respond to Suresh=E2=80=99s second =
paragraph, and I don=E2=80=99t find changes in version 10 related to it.
> >>>
> >>> I think that to clear Suresh=E2=80=99s DISCUSS, the draft needs to at=
 least include a short discussion of the potential for backwards compatibil=
ity issues, and to clarify the normative language around as described in hi=
s second paragraph.
> >>>
> >>> Suresh: Do you agree?
> >>
> >> Yes. I agree. I am fine even if the text simply says some legacy imple=
mentations may no longer be compliant because of this change.
> >>
> >> Thanks
> >> Suresh
> >>
> >
>


From nobody Thu Aug 23 13:42:50 2018
Return-Path: 
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 455CF130F01; Thu, 23 Aug 2018 13:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2Inoe7TCRcJ4; Thu, 23 Aug 2018 13:42:47 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD2F130EFE; Thu, 23 Aug 2018 13:42:47 -0700 (PDT)
Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7NKghZd040887 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Aug 2018 15:42:44 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95]
From: Ben Campbell 
Message-Id: <9FF5AC7A-CB6B-4C5B-9B4F-8E124BABD5BD@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F017351A-1557-4F2B-BCE7-2D3BD64C8146"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 23 Aug 2018 15:42:42 -0500
In-Reply-To: 
Cc: ddolson@acm.org, "jouni. nospam" , draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org, IESG 
To: Suresh Krishnan 
References: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net>  <5BCB718E-29E6-401C-9AF0-55AEE6435159@gmail.com> <42a2c82f-2401-1774-97ee-071b11b9e58c@golden.net> <760D014C-05DC-461F-AFE4-38FE5FD694D1@nostrum.com> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Aug 2018 20:42:48 -0000

--Apple-Mail=_F017351A-1557-4F2B-BCE7-2D3BD64C8146
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If I understand correctly, there needs to be at least one more version =
for unrelated reasons. Therefore I prefer that the authors add the text =
to the update.

Thanks!

Ben.

> On Aug 23, 2018, at 3:38 PM, Suresh Krishnan =
 wrote:
>=20
> Hi Dave/Ben,
>  This new text suggestion fully addresses my DISCUSS. I will clear as
> soon as the new version hits (or if Ben can add an RFC editor note, I
> will clear right away).
>=20
> Regards
> Suresh
> On Wed, Aug 22, 2018 at 6:17 PM Ben Campbell  wrote:
>>=20
>> Hi,
>>=20
>> I agree this should go in 8.38, not in the appendix.
>>=20
>> Would something to the effect of the following make sense?
>>=20
>> "Because RFC5952 is more restrictive than the RFC3513 format required =
by RFC4006, some legacy implementations may not be compliant with the =
new requirements. Accordingly, implementations receiving this AVP MAY be =
liberal in the textual IPv6 representations that are accepted without =
raising an error.=E2=80=9D
>>=20
>> Thanks!
>>=20
>> Ben.
>>=20
>>> On Aug 21, 2018, at 8:31 PM, Dave Dolson  wrote:
>>>=20
>>> Would a backwards compatibility statement go in section 8.38 itself, =
or in the appendix C (Changes relative to RFC4006)?
>>>=20
>>> I suggest that in section 8.38, the following paragraph be added:
>>>=20
>>> "Because RFC5952 is more restrictive than the RFC3513 format =
required by RFC4006, implementations receiving this AVP MAY be liberal =
in the textual IPv6 representations that are accepted without raising an =
error."
>>>=20
>>> Comments?
>>> -Dave
>>>=20
>>> On 2018-08-15 1:14 PM, Suresh Krishnan wrote:
>>>> Hi Ben,
>>>>=20
>>>>=20
>>>>> On Aug 13, 2018, at 5:10 PM, Ben Campbell  wrote:
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> I don=E2=80=99t think Suresh=E2=80=99s DISCUSS has been resolved =
in revision 10.Please see inline:
>>>>>=20
>>>>> Thanks!
>>>>>=20
>>>>> Ben.
>>>>>=20
>>>>>> On May 23, 2018, at 9:03 PM, Dave Dolson  =
wrote:
>>>>>>=20
>>>>>> Suresh,
>>>>>>=20
>>>>>> Please see inline.
>>>>>>=20
>>>>>>=20
>>>>>> On 2018-05-23 04:55 PM, Suresh Krishnan wrote:
>>>>>>> Suresh Krishnan has entered the following ballot position for
>>>>>>> draft-ietf-dime-rfc4006bis-08: Discuss
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>>>=20
>>>>>>>=20
>>>>>>> The document, along with other ballot positions, can be found =
here:
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> =
----------------------------------------------------------------------
>>>>>>> DISCUSS:
>>>>>>> =
----------------------------------------------------------------------
>>>>>>>=20
>>>>>>> Section 8.38.
>>>>>>>=20
>>>>>>> RFC5952 contains significant changes in text representation from =
RFC3513 and I
>>>>>>> am concerned that there might be RFC4006 compliant =
implementations that will no
>>>>>>> longer be legal with a MUST level use of RFC5952. e.g. Addresses =
with upper
>>>>>>> case hex digits, with leading zeroes in 16 bit fields etc. Has =
the working
>>>>>>> group considered this break in compatibility already in its =
discussions?
>>>>>>>=20
>>>>>>> If it has, this text should still be finessed a bit because =
RFC5952
>>>>>>> recommendations (even at the MUST level) are a SHOULD for =
senders with the
>>>>>>> receivers being required to handle all possible legal formats as =
per RFC4291.
>>>>>>> So at least the sender rules and receiver rules need to be =
written differently.
>>>>>> If I recall correctly, we did give this some thought. RFC 5952 =
was presumably done for a reason, due to flaws in previous descriptions =
of address format. Hence it is prudent to use the new requirements. =
Implementations are free to be liberal in what they receive, for =
backwards compatibility with RFC 4006.
>>>>>> So I think it's fair to say this standard requires use of RFC =
5952 syntax.
>>>>>=20
>>>>> I cannot find evidence of discussion on the DIME list about =
backwards compatibility related to the RFC 5952 encoding.
>>>>>=20
>>>>> Authors/Shepherd: Are you aware of something I missed? Maybe this =
was discussed in a meeting? Does anyone know whether existing =
implementations are typically compatible with 5952? (I guess this is =
most commonly used in 3GPP networks; does anyone know if the relevant =
3GPP specs have anything to say bout 5952 vs 3513 encoding?)
>>>>>=20
>>>>> In any case, this doesn=E2=80=99t respond to Suresh=E2=80=99s =
second paragraph, and I don=E2=80=99t find changes in version 10 related =
to it.
>>>>>=20
>>>>> I think that to clear Suresh=E2=80=99s DISCUSS, the draft needs to =
at least include a short discussion of the potential for backwards =
compatibility issues, and to clarify the normative language around as =
described in his second paragraph.
>>>>>=20
>>>>> Suresh: Do you agree?
>>>>=20
>>>> Yes. I agree. I am fine even if the text simply says some legacy =
implementations may no longer be compliant because of this change.
>>>>=20
>>>> Thanks
>>>> Suresh
>>>>=20
>>>=20
>>=20


--Apple-Mail=_F017351A-1557-4F2B-BCE7-2D3BD64C8146
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlt/HEIACgkQgFZKbJXz
1A1egg//Xq4QwCwiWtdzLQK5E7hGv1oMnZSBkpAqZKggOiyuL+ucC3cR3uFa6xWz
Wcr/abq36cmnZdTJVbqKUfuvg741q8dCfiz/iMxO9j6dxEsHKjlZZrt/YYh7HQV4
d7qBt17vVfp8NP6NqCZ3Vah1HeghpJeVp0LQ4HV04kcG96NWtuONZQ8aB+LrDSmX
qM7nGeRREg9m0uJQGnPfswLFmabAMuf/v8GrdMjJNVu7vEroe7GYLVONWTFE7xCv
kA6xLR8DMhDx14rFDKWOtNHn1n15yrc5d8OiOLoCTRu73gedhFstG0rDhkY0m13y
PeyhOSHCe30ygL+NzAnzuBNVo6fAW2IUUW8iXh72DUM9FDyTrqtnPOx7YLtErFJM
M1NIBZ3o5UBTHBxTbKAG/KtJg2ESp9Vy6Fpdi5u3szxY1TYW51FvYF1XSB/3aEk3
d/sVYi9JymzTeMSDZKRx3Kq8w7FP9/38nT6Ev6tvH6y4t+3s2yks8PZExMsORCMS
tISwMFvTpcGsIkyB7/yYfVTcxvjYm+KmejXvE2kHVkB/DDHnLPiQVNI0oEnyIWP/
12ZSvo5N35MwkEFhOStns0BOZnO/b/2tQD2CKSkFrs5IYydeN0Di2ufqfjFZi/FW
TtI88NA6GXS6CSylHzIbpmpnooYxOZcwDtM6HApXLVShKK6FkCo=
=IvOP
-----END PGP SIGNATURE-----

--Apple-Mail=_F017351A-1557-4F2B-BCE7-2D3BD64C8146--


From nobody Sun Aug 26 04:06:58 2018
Return-Path: 
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC2130DD6; Sun, 26 Aug 2018 04:06:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: dime@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: dime@ietf.org
Message-ID: <153528161725.11926.7566004863853048091@ietfa.amsl.com>
Date: Sun, 26 Aug 2018 04:06:57 -0700
Archived-At: 
Subject: [Dime] I-D Action: draft-ietf-dime-rfc4006bis-11.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Aug 2018 11:06:57 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Diameter Maintenance and Extensions WG of the IETF.

        Title           : Diameter Credit-Control Application
        Authors         : Lyle Bertz
                          David Dolson
                          Yuval Lifshitz
	Filename        : draft-ietf-dime-rfc4006bis-11.txt
	Pages           : 127
	Date            : 2018-08-26

Abstract:
   This document specifies a Diameter application that can be used to
   implement real-time credit-control for a variety of end user services
   such as network access, Session Initiation Protocol (SIP) services,
   messaging services, and download services.  The Diameter Credit-
   Control application as defined in this document obsoletes RFC4006,
   and it must be supported by all new Diameter Credit-Control
   Application implementations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-11
https://datatracker.ietf.org/doc/html/draft-ietf-dime-rfc4006bis-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-rfc4006bis-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Aug 26 04:10:34 2018
Return-Path: 
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 42458130DD7 for ; Sun, 26 Aug 2018 04:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 zYwxpHMEthWK for ; Sun, 26 Aug 2018 04:10:29 -0700 (PDT)
Received: from sonic316-15.consmr.mail.bf2.yahoo.com (sonic316-15.consmr.mail.bf2.yahoo.com [74.6.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD461130DD1 for ; Sun, 26 Aug 2018 04:10:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1535281828; bh=Jm0NyOwkgoFvFcNLBQXpBKnYeHbg5CqtacFlCP9uLAc=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=Cm8tvZpkMUKiKM4iziLtcr4C9f5nVWqwUqgzcrqreq59NGiU3lqSS2BQCCDu7o9gIZy6BYs51J+JFh0hViLIBj78NSfwWCyKvbTto/OKnPyLo62EYlaWbWMQmJCZV5ZXaUP8G5R/KVStO+QrZ/LqhQO+GF5cRzNM0fX2PGAhBY2DDgRn8o6jwxBesbAC1Wgbb4YcwFxq7oYc6laR6S8Yjzy5H+k77A3nv9aomzy126a2vH3T0+0my6e0ljfLxfx0qjdsc3Ga1iR7GnNmG9RCoccnbBGZnYh/T+dK74pLqZTDpuou4SI6X0AOiIjG6EwRKGktEPUHpS8ypnkK4StjdQ==
X-YMail-OSG: C1YkuAsVM1l1fno82oYJJOVBE.kHX5_0lIemw.s6Hpkw863cjYaTKTEFyqZ0xVZ YnnmU1EHAytPb7bEZxBGCeQ8vz_FrzkZsr0L8j8YdeZIHwGDqeO0ih_ftbdCo.11kV0vwOK1CH6p 4skEjLtpd8VYzQOnXZ_MQltpa6bZcjjvy7znUHgV9dWI4NdYdKNXDVNxx_28veq5Dxn8bELWKpSc R3VqOaOoECF83TNUyvwzM5uuABPU4RByCPN8z0du4oCcTrowX3_Cu2HNvP24rxJdGvH.dreU4eQY Q0RxQQTz2eXki1RJ60_76xFHcI5pqhI8vSq3ayecCSWlzt114dREy79PlWXeLXHw7C8gkmHCxylM RpuwFw_gOiEPNljBKJbgl_nURyqh5yXbP2fiRo0JcVeBewdj.ejjXSriWm.MfO3P.4kK1qaEVoLE 7U0xvdI68LswDYA6xdQY6u9DWxf8MIC_Tf51yza5B.2Ci4vrWJLYmwPADzY2a_J7EDibWFhQb7Bx B1ZS09Mf9irRsp1W6ks2OZGmcbFHhJhJDDc1G8UNRrxhm6gFH6prtFADKXiR7K60FLI5TYMirx8y jIJRCR05e3YM6zZaqEixrscA4yxAGA1kfH9VM8J.qdXSz4QT0CxMcyXORvIbBZfK2o2MNt80cDUT NdZR8Pk2vgldUqXeuADD7BXijkGW78s2HNQ0ZRzKSLRXry47_zk7ZibYsYbNWPdWYeuM_n2erGjQ Wq5.6xeQ6YPFSX9kBzD.XMkHq2QopL2LVYtoG.jnErhqkS1uJQN1f4gEurmO_PLMgNuvTRjbzfpj fWiz3aJFW7lGFNNdTpVIchXPPEPBEmSDVtrT8hOYvq4qBqfkmJ0mtC4.joWvtQR9QtLCAatCxRH3 GDV1CJ_4XPFo0Cp3n7jsHj_HZcNxzhacAOaWsI1AqJLczW8i4Z2.ANn59nMExClJARz5mqi0kxk6 BvYwMVSu2CDMP3RVB0hM7nLp8W_YpT_Y5P_s70TRV0w_WdQ--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Sun, 26 Aug 2018 11:10:28 +0000
Date: Sun, 26 Aug 2018 11:09:50 +0000 (UTC)
From: Yuval Lifshitz 
To: i-d-announce@ietf.org,  
Message-ID: <170132843.2752923.1535281790876@mail.yahoo.com>
In-Reply-To: <153528161725.11926.7566004863853048091@ietfa.amsl.com>
References: <153528161725.11926.7566004863853048091@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_2752922_910716053.1535281790874"
X-Mailer: WebService/1.1.12262 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36
Archived-At: 
Subject: Re: [Dime] I-D Action: draft-ietf-dime-rfc4006bis-11.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Aug 2018 11:10:31 -0000

------=_Part_2752922_910716053.1535281790874
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi All,Revision 11 addresses 2 recent issues:* Clarification on backward co=
mpatibility of IPv6 formats* Remove contradictions between=C2=A0section 8.6=
8 and 8.64
Yuval
   On Sunday, August 26, 2018, 2:07:04 p.m. GMT+3,  wrote: =20
=20
=20
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Diameter Maintenance and Extensions WG of =
the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Diame=
ter Credit-Control Application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : Lyle Bertz
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 David Dolson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Yuval Lifshitz
=C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-dime-rf=
c4006bis-11.txt
=C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 127
=C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2018-08-=
26

Abstract:
=C2=A0 This document specifies a Diameter application that can be used to
=C2=A0 implement real-time credit-control for a variety of end user service=
s
=C2=A0 such as network access, Session Initiation Protocol (SIP) services,
=C2=A0 messaging services, and download services.=C2=A0 The Diameter Credit=
-
=C2=A0 Control application as defined in this document obsoletes RFC4006,
=C2=A0 and it must be supported by all new Diameter Credit-Control
=C2=A0 Application implementations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-11
https://datatracker.ietf.org/doc/html/draft-ietf-dime-rfc4006bis-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-rfc4006bis-11


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 =20
------=_Part_2752922_910716053.1535281790874
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi All,
Revisio=
n 11 addresses 2 recent issues:
* Clarification on backward compa=
tibility of IPv6 formats
* Remove contradictions between section 8.68 and 8.64

Yuval


            

               =20
                

                    On Sunday, August 26, 2018, 2:07:04 p.m. GMT+3,  <in=
ternet-drafts@ietf.org> wrote:
                

                


                


                

A New Inte=
rnet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Diameter Maintenance =
and Extensions WG of the IETF.

        Title         =
;  : Diameter Credit-Control Application
  &=
nbsp;     Authors         : Lyle Bertz
               =
           David Dolson
=
                     =
;     Yuval Lifshitz
   =
 Filename        : draft-ietf-dime-rfc4006bis-11.txt
    Pages       =
    : 127
    Date  &nbs=
p;         : 2018-08-26

<=
/div>
Abstract:
   This docu=
ment specifies a Diameter application that can be used to
   implement real-time credit-control for a variety of end us=
er services
   such as network access, Sessi=
on Initiation Protocol (SIP) services,
   me=
ssaging services, and download services.  The Diameter Credit-
   Control application as defined in this document =
obsoletes RFC4006,
   and it must be support=
ed by all new Diameter Credit-Control
   App=
lication implementations.


The IETF datatracker status page for this dr=
aft is:

There are also htmlized versions available at:
<=
div dir=3D"ltr">https://tools.ietf.org/html/draft-ietf-dime-rf=
c4006bis-11

A diff from the previous version is=
 available at:


Please note =
that it may take a couple of minutes from the time of submission
<=
div dir=3D"ltr">until the htmlized version and diff are available at tools.=
ietf.org.

Internet-Dra=
fts are also available by anonymous FTP at:

_______________________________________________
DiME mailing list

            

        

------=_Part_2752922_910716053.1535281790874--


From nobody Sun Aug 26 09:52:32 2018
Return-Path: 
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8311612008A; Sun, 26 Aug 2018 09:52:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 
To: "The IESG" 
Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153530235052.11926.9671135527180009683.idtracker@ietfa.amsl.com>
Date: Sun, 26 Aug 2018 09:52:30 -0700
Archived-At: 
Subject: [Dime] Benjamin Kaduk's No Objection on draft-ietf-dime-rfc4006bis-11: (with COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Aug 2018 16:52:31 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dime-rfc4006bis-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my DISCUSS points.  Original ballot comments preserved below:

Some additional significant but not necessarily DISCUSS-worthy
comments, followed by more editorial- and nit-level things.

In Section 1.3, "Advertising Application Support" uses the same
Auth-Application-ID value as for RFC 4006; what are the interop
consequences of this?

Alissa already noted that the text about how to split (sub-)AVPs
between the foo and foo-Extension AVPs is inconsistent among them --
e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD
send [in the old one]", but Subscription-Id-Extension has separate
text about "[i]f full backward compatibility with [RFC4006] is
required" and slightly different behavior described.  We should try
to catch all instances of this sort of backwards compatibility and
make them consistent.

The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL)
might benefit from additional text about the expected contents.  A
lot of the time when we use a UTF8 container for names (whether
domain names or other kinds), we specify what normalization form and
canonicalization are performed, whether domain names are A-labels or
U-labels, etc., as there's a lot of potential flexibility not all of
which is good.  In this case, since the communication is only
between trusted actors, perhaps the additional restrictions are not
needed, but I am curious if the topic was raised in the WG.

Thank you for adding the Privacy Considerations and list of
Privacy-Sensitive AVPs!

Section 14

   [...] The Diameter credit-
   control application is often used within one domain, and there may be
   a single hop between the peers.  In these environments, the use of
   TLS/TCP, DTLS/SCTP or IPsec is sufficient.

I did not see any concrete guidance on what would suffice in other
environments (with multiple hops between peers).  Is this the realm
of the mythical "end-to-end security mechanism" for Diameter that is
much-desired?  (The last paragraph does have guidance on what might
*not* suffice, which is not exactly the same thing.)

   Even without any modification to the messages, an adversary can
   eavesdrop on transactions that contain privacy-sensitive information
   about the user.

This ("an adversary can") makes it sounds as if there is no
confidentiality protection anywhere in the system, but that's what
TLS/DTLS/IPSec are supposed to provide.  So maybe "an adversary that
can eavesdrop on transactions can obtain privacy-sensitive
information [...]" is better.

(Editorial- and nit-level stuff follows.)

Section 4

   A flexible credit-control application specific failure handling is
   defined in which the home service provider can model the credit-
   control client behavior according to its own credit risk management
   policy.

This sentence is hard to parse -- in "credit-control application
specific" what does "specific" bind to?  What is being modelled?  Is
anything being controlled (as opposed to modelled)?

Section 4.1.1

   2.  The Service-Parameter-Info AVP MAY be used as a container to pass
   legacy rating information in its original encoded form (e.g., ASN.1
   BER).  [...]

Why BER and not DER?  The unnecessary flexibility in BER vs. DER has
been known to tickle parser bugs and create security
vulnerabilities.

Section 4.1.2

   [...] To
   facilitate interoperability, it is RECOMMENDED that the rating input
   and the values of the Service-Context-Id be coordinated via an
   informational RFC or other permanent and readily available reference.
   The specification of another cooperative standardization body (e.g.,
   3GPP, OMA, or 3GPP2) SHOULD be used.

The RECOMMENDED and SHOULD seem slightly in conflict.

Section 5.1.1

As noted elsewhere, 60 seconds per minute does not always hold; it
seems that this text could be reworded to just talk about a
"constant rate" or "constant level per fixed time period" or
similar.

Section 5.1.2

   [...]
   timer (Section 13) every time a CCR message with the value
   UPDATE_REQUEST is sent while they are in PendingU state.  When
   answers to all pending messages are received, the state machine moves
   to OPEN state, and Tx is stopped.

Transmission, or the Tx timer (is stopped)?

Using a different title for Section 5.2.2 might make the parallel
between it and Section 5.2.1 more clear.  That is, perhaps something
like "First Interrogation Included with Authorization Messages".

Section 5.7

   [...] It is RECOMMENDED that the client complement the credit-
   control failure procedures with backup accounting flow toward an
   accounting server. [...]

Nit: it looks like there's a missing article here, maybe "a backup
accounting flow" is better.

   The AAA transport profile [RFC3539] defines the application layer
   watchdog algorithm that enables failover from a peer that has failed
   and is controlled by a watchdog timer (Tw) defined in [RFC3539].

Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm?

Section 6.2

Should there be text indicating how the client indicates what
service the balance check is being requested for?

Section 8.54

Maybe give a section reference in RFC 3580 for how the formatting is
done?

Section 12

   [...] Initially, such Expert discussions take place on the AAA
   WG mailing list.

That list appears to be dead, suggesting that this text should be
updated.  (I also agree with Adam's comments about updating the IANA Considerations.)

Why is the disclaimer in Section B.4 (and other examples) not needed in Section B.3?



From nobody Mon Aug 27 08:01:57 2018
Return-Path: 
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 912E6130DFD; Mon, 27 Aug 2018 08:01:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan 
To: "The IESG" 
Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153538211458.30033.3766934915165411264.idtracker@ietfa.amsl.com>
Date: Mon, 27 Aug 2018 08:01:54 -0700
Archived-At: 
Subject: [Dime] Suresh Krishnan's No Objection on draft-ietf-dime-rfc4006bis-11: (with COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Aug 2018 15:01:55 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-dime-rfc4006bis-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my DISCUSS point.

Section 8.65

Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped IPv6
Address while you can directly use address family 1 to encode it directly as an
IPv4 address? This allows for two different encodings for the same address.



From nobody Mon Aug 27 14:16:56 2018
Return-Path: 
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD4E130E39; Mon, 27 Aug 2018 14:16:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: ben@nostrum.com, The IESG , jouni.nospam@gmail.com, Jouni Korhonen , draft-ietf-dime-rfc4006bis@ietf.org,  dime-chairs@ietf.org, dime@ietf.org, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <153540460157.30070.289720327931276364.idtracker@ietfa.amsl.com>
Date: Mon, 27 Aug 2018 14:16:41 -0700
Archived-At: 
Subject: [Dime] Protocol Action: 'Diameter Credit-Control Application' to Proposed Standard (draft-ietf-dime-rfc4006bis-11.txt)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Aug 2018 21:16:42 -0000

The IESG has approved the following document:
- 'Diameter Credit-Control Application'
  (draft-ietf-dime-rfc4006bis-11.txt) as Proposed Standard

This document is the product of the Diameter Maintenance and Extensions
Working Group.

The IESG contact persons are Warren Kumari, Ignas Bagdonas and Ben Campbell.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/




Technical Summary

   This document will obsolete RFC4006. This document specifies a Diameter application
   that can be used to implement real-time credit-control for a variety of end user services.

Working Group Summary

  WG has a solid support for this document.

Document Quality

   3GPP has adopted RFC4006 and it has been widely implemented, deployed
   and in production use basically in every cellular carrier with LTE deployment.
   The changes/updates described in this specification are not deployed but
   being one of the core Diameter specifications in 3GPP there are high probability
   it getting a wide deployment. Maintaining backward compatibility was one of the
   design guidelines. The update to RFC4006, which this document is, was  requested
   by 3GPP.
  
   There has not been any expert reviews of the document. 

Personnel

   Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
   Ben Campbell (ben@nostrum.com) is the responsible AD.