Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)

Ben Campbell <ben@nostrum.com> Wed, 22 August 2018 22:18 UTC

Return-Path: <ben@nostrum.com>
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 <ben@nostrum.com>
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 <suresh.krishnan@gmail.com>, Jouni Korhonen <jouni.nospam@gmail.com>, draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG <iesg@ietf.org>
To: Dave Dolson <ddolson@acm.org>
References: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net> <C0DC5469-01F4-4DFE-80D7-707D6F1CC933@nostrum.com> <5BCB718E-29E6-401C-9AF0-55AEE6435159@gmail.com> <42a2c82f-2401-1774-97ee-071b11b9e58c@golden.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/0qTtQmlZ7FGNYtQDX7g15WZK37k>
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 <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Aug 2018 22:18:06 -0000

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
>> 
>