[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

"Pearl Liang via RT" <drafts-lastcall@iana.org> Thu, 19 March 2015 15:50 UTC

Return-Path: <iana-shared@icann.org>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601811A1A64; Thu, 19 Mar 2015 08:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 jeJROapT7uVl; Thu, 19 Mar 2015 08:50:34 -0700 (PDT)
Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017031A1A0C; Thu, 19 Mar 2015 08:50:33 -0700 (PDT)
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2JFoXJf027070; Thu, 19 Mar 2015 15:50:33 GMT
Received: by request3.lax.icann.org (Postfix, from userid 48) id C0B63C20366; Thu, 19 Mar 2015 15:50:33 +0000 (UTC)
RT-Owner: pearl.liang
From: "Pearl Liang via RT" <drafts-lastcall@iana.org>
In-Reply-To: <20150307002447.20539.31287.idtracker@ietfa.amsl.com>
References: <RT-Ticket-811747@icann.org> <20150307002447.20539.31287.idtracker@ietfa.amsl.com>
Message-ID: <rt-4.2.9-1264-1426780233-1255.811747-7-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #811747
X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/)
X-RT-Originator: pearl.liang@icann.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Thu, 19 Mar 2015 15:50:33 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/EAKRZxnsckENb98lafrEtiEttH4>
X-Mailman-Approved-At: Fri, 20 Mar 2015 11:23:20 -0700
Cc: iesg@ietf.org, radext@ietf.org, radext-chairs@ietf.org, draft-ietf-radext-dynamic-discovery.all@ietf.org
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
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: drafts-lastcall@iana.org
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: <http://www.ietf.org/mail-archive/web/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, 19 Mar 2015 15:50:36 -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 <iesg@ietf.org>

      Contact: IETF Chair <chair@ietf.org>

      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, iesg-secretary@ietf.org 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
> ietf@ietf.org mailing lists by 2015-03-20. Exceptionally, comments may be
> sent to iesg@ietf.org 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.
> 
>