Subject: [radext] [IANA #811747] Last Call: <draft-ietf-radext-dynamic-discovery-13.txt> (NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS) to Experimental RFC

From: "Pearl Liang via RT" <[email-masked]>
Date: Thu, 19 Mar 2015 15:50:33 +0000

(BEGIN IANA LAST CALL COMMENTS)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-radext-dynamic-discovery-13.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions for the IANA actions requested in this draft.  Further, some 
of the new requested values require Expert review. 

IANA understands that, upon approval of this document, there are six actions which must be completed.

First, in the S-NAPTR Application Service Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/

three, new service tags will be registered as follows:

Tag: aaa+auth
Reference: [ RFC-to-be ]

Tag: aaa+accr
Reference: [ RFC-to-be ]

Tag: aaa+dynauth
Reference: [ RFC-to-be ]

IANA Note --> As this document requests registrations in a Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the S-NAPTR Application Protocol Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/

two, new service tags will be registered as follows:

Tag: radius.tls.tcp
Reference: [ RFC-to-be ]

Tag: radius.dtls.udp
Reference: [ RFC-to-be ]

IANA Note --> As above, this document requests registrations in a Specification Required registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, this document requests two service names - radiustls and radiusdtls - to be registered for both TCP and UDP in the Service Name and Transport Protocol Port Number Registry located at:

http://www.iana.org/assignments/service-names-port-numbers

      Service Name: radiustls; radiusdtls

      Transport Protocols: TCP, UDP

      Assignee: IESG <[email-masked]>

      Contact: IETF Chair <[email-masked]>

      Description: Authentication, Accounting and Dynamic authorization
      via the RADIUS protocol.  These service names are used to
      construct the SRV service labels "_radiustls" and "_radiusdtls"
      for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively.

      Reference: [RFC-to-be]

Question: What are the Defined TXT keys for each SRV names?
The Defined TXT keys are required for SRV service names.

The authors should submit a template at http://www.iana.org/form/ports-services for early allocation and put the Internet Draft as a reference according to RFC6335 as stated in section 8.1.1 of that document.  

Fourth, IANA understands that this draft makes use of the SRV Protocol identifiers "_tcp" and "_udp" which are mentioned as early as [RFC2782] but do not appear to be assigned in an actual registry. IANA is unable to find these assigned in any SRV Protocol related registry. IANA understands that the authors are choosing not to requesting a new registry "RADIUS/TLS SRV Protocol Registry" to support the formal registration of those identifiers.

Fifth, a new value will be registered in the "SMI Security for PKIX Module Identifier Registry" which is located in:

in http://www.iana.org/assignments/smi-numbers

IANA notes that the authors have provided the following for a description:

TBD99   id-mod-nai-realm-08   [RFC-to-be]

IANA Note --> As this document requests registrations in a Specification Required registry as per RFC7299, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Sixth, a new value will be registered in the "SMI Security for PKIX Other Name Forms Registry which is located in:

in http://www.iana.org/assignments/smi-numbers

IANA notes that the authors have provided the following for a description:

TBD98     id-on-nai   [RFC-to-be]

IANA Note --> As this document requests registrations in a Specification Required registry as per RFC7299, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these six actions are the only ones required to be ocmpleted upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.  

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. 

Thanks,

Pearl Liang
ICANN

(END IANA LAST CALL COMMENTS)

On Sat Mar 07 00:25:13 2015, [email-masked] wrote:
> 
> The IESG has received a request from the RADIUS EXTensions WG (radext) to
> consider the following document:
> - 'NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS'
>   <draft-ietf-radext-dynamic-discovery-13.txt> as Experimental RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-03-20. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document specifies a means to find authoritative RADIUS servers
>    for a given realm.  It is used in conjunction with either RADIUS/TLS
>    and RADIUS/DTLS.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
>

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Thu, 19 Mar 2015 15:50:33 +0000

IESG/Authors/WG Chairs:

Tag: aaa+auth
Reference: [ RFC-to-be ]

Tag: aaa+accr
Reference: [ RFC-to-be ]

Tag: aaa+dynauth
Reference: [ RFC-to-be ]

Tag: radius.tls.tcp
Reference: [ RFC-to-be ]

Tag: radius.dtls.udp
Reference: [ RFC-to-be ]

      Reference: [RFC-to-be]

Thanks,

Pearl Liang
ICANN

---

From: Stefan Winter <[email-masked]>
Date: Fri, 20 Mar 2015 09:52:41 +0100

Hello,

two comments:
> First, in the S-NAPTR Application Service Tags subregistry of the
> Straightforward-NAPTR (S-NAPTR) Parameters registry located at:
> 

There is a typo in your mail: the draft registers aaa+acct (note a t at
the end, like "accounTing"). All occurences in the draft are for acct;
no mention at all of accr.

> The Defined TXT keys are required for SRV service names.

I think I disagree (but I'm not quite sure ;-) . Reading RFC6763 Section
6, I read:

"Note that this requirement for a mandatory TXT record applies
   exclusively to DNS-SD service advertising, i.e., services advertised
   using the PTR+SRV+TXT convention specified in this document.  It is
   not a requirement of SRV records in general.  The DNS SRV record
   datatype [RFC2782] may still be used in other contexts without any
   requirement for accompanying PTR and TXT records."

As defined in the draft, the service name is NOT registered for DNS-SD
and makes no use of accompanying PTR and TXT records. It is defined
following RFC2782, defining a "Name" in that RFCs notion and if anything
has an accompanying NAPTR.

Please advise if you still insist on the definiton of a TXT.

> The authors should submit a template at http://www.iana.org/form/ports-services for early allocation and put the Internet Draft as a reference according to RFC6335 as stated in section 8.1.1 of tha…

Will do. I've submitted the two forms without a TXT now, hoping that
IANA's answer to the above is "TXT is not required".

I believe the other four issues do not require intervention by the
authors; these are between IANA and the experts. If I'm wrong, please
let me know.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Fri, 20 Mar 2015 17:05:07 +0000

Hello,

We received this message you sent on 09:52:41 GMT.

Thanks,
~pl

On Fri Mar 20 09:17:30 2015, [email-masked] wrote:
> > Third, this document requests two service names - radiustls and
> > radiusdtls - to be registered for both TCP and UDP in the Service
> > Name and Transport Protocol Port Number Registry located at:
> >
> > The authors should submit a template at
> > http://www.iana.org/form/ports-services for early allocation and put
> > the Internet Draft as a reference according to RFC6335 as stated in
> > section 8.1.1 of that document.
>

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Mon, 23 Mar 2015 16:45:30 +0000

Hello,

Please see inline comments.

> > no mention at all of accr.

Thanks for catching that.  

> > I think I disagree (but I'm not quite sure ;-) . Reading RFC6763

Sure.  We simply put 'None' for that field if there is nothing filled in 
the request.

We are working on the new assignments you submitted via the template
form.

> > authors; these are between IANA and the experts. If I'm wrong, please

Those require expert review are pending experts' replies.  I'm not sure what
you mean by "between IANA and the experts."  We only initiate the expert 
review.  If experts have questions, we will forward their comments to 
the authors, and the authors should answer experts' questions.

Thanks
~pl

Pearl Liang
ICANN