[radext] [IANA #814387] Re: 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> Mon, 23 March 2015 16:45 UTC

Return-Path: <iana-shared@icann.org>
X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org
Delivered-To: radext@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 119AF1ACD94; Mon, 23 Mar 2015 09:45:48 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EB31ACD93; Mon, 23 Mar 2015 09:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level:
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_55=0.6, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 dNI_R9jdeZHd; Mon, 23 Mar 2015 09:45:45 -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 182951ACD7A; Mon, 23 Mar 2015 09:45:31 -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 t2NGjUgS000692; Mon, 23 Mar 2015 16:45:30 GMT
Received: by request3.lax.icann.org (Postfix, from userid 48) id CE51EC20682; Mon, 23 Mar 2015 16:45:30 +0000 (UTC)
RT-Owner: pearl.liang
From: "Pearl Liang via RT" <drafts-lastcall@iana.org>
In-Reply-To: <rt-4.2.9-12707-1426871106-1619.814387-7-0@icann.org>
References: <RT-Ticket-814387@icann.org> <RT-Ticket-811747@icann.org> <20150307002447.20539.31287.idtracker@ietfa.amsl.com> <rt-4.2.9-1264-1426780233-1255.811747-7-0@icann.org> <550BDFD9.2030700@restena.lu> <rt-4.2.9-12707-1426871106-1619.814387-7-0@icann.org>
Message-ID: <rt-4.2.9-2033-1427129130-1150.814387-7-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #814387
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: Mon, 23 Mar 2015 16:45:30 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/HBuB_Hd0MOPyJXP71s0pzOuHtdw>
X-Mailman-Approved-At: Mon, 23 Mar 2015 10:01:22 -0700
Cc: draft-ietf-radext-dynamic-discovery.all@ietf.org, iesg@ietf.org, stefan.winter@restena.lu
Subject: [radext] [IANA #814387] Re: 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: Mon, 23 Mar 2015 16:45:48 -0000

Hello,

Please see inline comments.

On Fri Mar 20 17:05:06 2015, pearl.liang wrote:
> Hello,
> 
> We received this message you sent on 09:52:41 GMT.
> 
> Thanks,
> ~pl
> 
> On Fri Mar 20 09:17:30 2015, stefan.winter@restena.lu wrote:
> > Hello,
> > 
> > two comments:
> > > 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 ]
> > 
> > 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.
> > 

Thanks for catching that.  

> > > 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.
> > 
> > I think I disagree (but I'm not quite sure ;-) . Reading RFC6763
> > Section

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.

> > 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 that document.
> > 
> > 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.
> > 

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



> > Greetings,
> > 
> > Stefan Winter
>