Re: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (with DISCUSS and COMMENT)

Alan DeKok <aland@deployingradius.com> Thu, 18 August 2016 16:36 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B622112D5D8; Thu, 18 Aug 2016 09:36:31 -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 cNHoVgyt6qOU; Thu, 18 Aug 2016 09:36:29 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8A68312DC60; Thu, 18 Aug 2016 09:36:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 7B0E5C0D; Thu, 18 Aug 2016 16:36:23 +0000 (UTC)
Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7ZjTmKFzXOv; Thu, 18 Aug 2016 16:36:23 +0000 (UTC)
Received: from [10.192.3.201] (LStLambert-657-1-56-254.w80-13.abo.wanadoo.fr [80.13.33.254]) by mail.networkradius.com (Postfix) with ESMTPSA id 0A20C772; Thu, 18 Aug 2016 16:36:22 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <147140538762.19947.17983354603426554979.idtracker@ietfa.amsl.com>
Date: Thu, 18 Aug 2016 18:36:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF628B01-AD10-4C33-970D-754295F2AA25@deployingradius.com>
References: <147140538762.19947.17983354603426554979.idtracker@ietfa.amsl.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/QYUVgA1uLrh5N0h5Es3zdGUdk44>
Cc: Winter Stefan <stefan.winter@restena.lu>, radext@ietf.org, draft-ietf-radext-datatypes@ietf.org, The IESG <iesg@ietf.org>, radext-chairs@ietf.org
Subject: Re: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (with DISCUSS and COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 16:36:32 -0000

On Aug 17, 2016, at 5:43 AM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
> * Section 3.10
> 
> It is not clear from this definition how exactly a sender needs to encode
> this attribute on the wire. e.g. From the spec it looks like an IPv6
> prefix such 2001:db8:dead:beef::/64 can legally be encoded using anywhere
> between 8 octets and 16 octets. What exactly is the preferred encoding?
> If you intend to allow all of the encodings can you please add an
> explicit statement to say so.

  The preferred encoding should be the shortest one.  I'll put some text together.

> * I am not sure why this document uses Reserved fields in sections 3.10
> and 3.11. Is it for alignment? Please clarify. I don't see exactly why
> aligning a 4 octet or a 16 octet value to a 16 bit boundary would provide
> any value. 
> (I personally think such padding related stuff should be in the
> definition of the radius attribute that uses the datatype and not in the
> datatype itself but I will not block on this.)

  The data types in 3.10 and 3.11 are taken from previous specifications.  I'm not entirely sure why they have reserved fields, either.

  We can't change the format of the data type, because implementations use this format.  The document just codifies existing practices.
 
> * Section 3.7
> 
> I think this text is confusing because "octet string" and network byte
> order do not seem to be compatible. Suggest rewording
> 
> OLD:
> The "ifid" data type encodes an Interface-Id as an 8-octet string in
>   network byte order
> 
> NEW:
> The "ifid" data type encodes an 8 octet IPv6 Interface Identifier in
>   network byte order

  Sounds good.

> * Section 3.10 and 3.11
> 
> The separator between the Reserved field and the Prefix Length field is
> off by one position.

  Fixed.