Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed;
 boundary="Apple-Mail=_CDEE4BBC-A3FB-49EE-8003-C44F9403BA41";
 protocol="application/pgp-signature"; micalg=pgp-sha256
From: Alan DeKok <aland@freeradius.org>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com>
Date: Tue, 9 Aug 2016 18:38:12 +0200
Message-Id: <0945BC67-129B-4B91-97FE-99D95367CB46@freeradius.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/19pMABdnrx7-uqWITtrP2wS3BGE>
Cc: "radext@ietf.org" <radext@ietf.org>,
 General Area Review Team <gen-art@ietf.org>,
 "draft-ietf-radext-datatypes.all@tools.ietf.org"
 <draft-ietf-radext-datatypes.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt
Precedence: list


--Apple-Mail=_CDEE4BBC-A3FB-49EE-8003-C44F9403BA41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Aug 9, 2016, at 5:28 PM, Romascanu, Dan (Dan) <dromasca@avaya.com> =
wrote:
> 1.       Although the document makes the claim that it does not impact =
previous specifications and implementations, I am not sure this is =
completely the case.

  As noted in the document, implementations have already chosen data =
types for all existing attributes.  I haven't seen any conflicting data =
types.  i.e. all implementations seem to have made the same choices.

  The document updates previous specifications, most notably where the =
specifications are inconsistent and/or wrong.  So it does impact =
previous specifications, but only to codify standard corrections.  Which =
(as noted above) all implementations have already fixed in practice.

> For example, the statement in RFC 6158, section 2.1 about 'all other =
data formats (than the ones defined there) being NOT RECOMMENDED is =
obsolete by this document. I think that there is a need to make clear =
what is not longer valid or recommended in specifications that this =
document updates

  Maybe this works:

This document updates [RFC6158] to permit the data types defined in
the "Data Type Registry" as "basic data types", as per Section 2.1 of
that document.  The recommendations of [RFC6158] are otherwise
unchanged.

  I think that should clarify the issue.

> 2.       This document creates a new IANA registry and updates another =
one. There is no mention however about the policy of adding new entries =
or making other modifications to the new registry. A reminder of the =
RADIUS Attribute Type registry policy would also help.

  The -06 rev has the following text:

4.1.  Create a Data Type Registry

   This section defines a new RADIUS registry, called "Data Type".
   Allocation in this registry requires IETF Review.  The "Registration
   Procedures" for this registry are "Standards Action".

  Which I think satisfies your concern.

> Minor issues:
>
> 1.       In section 3.5 =E2=80=93 there is no mention that the string =
length is limited to 253 octets. This is obvious if we assume the =
definition of  =E2=80=9Cstring=E2=80=9D sticking with previous RADIUS =
documents, and clear by the fact that =E2=80=9Cconcat=E2=80=9D deals in =
3.6 with transport of more than 253 octets, but for clarity I believe =
that this needs to be explicitly stated.

  Yes and no.  RFC 6929 allows for extended attributes to carry more =
than 253 octets of data.  The same comment applies to attributes of type =
"text".

  I'll add some text clarifying this.

> 2.       It is not clear why the Prefix-Length value greater than 128 =
for ipv6prefix in 3.10 and greater than 32 for ipv4prefix in 3.11 need =
only SHOULD be treated as =E2=80=9Cinvalid attributes=E2=80=9D. Why not =
MUST? If there are exception cases it would be good to explain them.

 The text was mostly taken from previous standards.  I'm OK with it =
being a MUST.

> Nits/editorial comments:
>
> 1.       Section 2.1.4: The paragraph that starts with =E2=80=98The =
=E2=80=9CValue=E2=80=9D field should be given =E2=80=A6.=E2=80=99 needs =
to use capitalized SHOULD to be consistent with the paragraph that refer =
to the =E2=80=9CName=E2=80=9D and =E2=80=9CFormat=E2=80=9D fields.


  Fixed, thanks.

  Alan DeKok.


--Apple-Mail=_CDEE4BBC-A3FB-49EE-8003-C44F9403BA41
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJXqgb0AAoJEH0Oec13Yh7NVh8H/iLkP3UQ0KNjb/o0BttIDO3n
/s66eb1j/vjACECo36qRR7BuUrZPlYDrtwsKEhNAMozDIxB9wu8+Kt9TwEKC+4pG
PuDpjPE2FVqjFkXHjO9WzFMtECG4TXCVmh7DL5qQh6MRLExNrVsolugBq4eWMA24
rQOTHCHznQzwxPQ1AdvzP2YKaLiI+g5is1mwYaSMo7YeBAe/iAfsLDOZ9gj3vfw4
FagglBBHnfoyZP8bYOxQ1D6e8I0l3KTBeT/uOvNqtbtKGx3U4DcoY7oILyuaWK3d
772l/YkOob/0Joa6/t+vdaw5VVzv3rw0MWKxTVSW+eiSMVbF65t77fHNHWE7Bvg=
=dR7m
-----END PGP SIGNATURE-----

--Apple-Mail=_CDEE4BBC-A3FB-49EE-8003-C44F9403BA41--