[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> Fri, 20 March 2015 17:05 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 31D231A89AE; Fri, 20 Mar 2015 10:05:09 -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 172FA1A6F2B; Fri, 20 Mar 2015 10:05:09 -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 tribzuSKgDhP; Fri, 20 Mar 2015 10:05:07 -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 681071A1BCB; Fri, 20 Mar 2015 10:05:07 -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 t2KH572s000796; Fri, 20 Mar 2015 17:05:07 GMT
Received: by request3.lax.icann.org (Postfix, from userid 48) id 2FDF9C203E9; Fri, 20 Mar 2015 17:05:07 +0000 (UTC)
RT-Owner: pearl.liang
From: "Pearl Liang via RT" <drafts-lastcall@iana.org>
In-Reply-To: <550BDFD9.2030700@restena.lu>
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>
Message-ID: <rt-4.2.9-12707-1426871106-957.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: Fri, 20 Mar 2015 17:05:07 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/QMqC62b6TmR0YmIbNBX1rZMls8A>
X-Mailman-Approved-At: Fri, 20 Mar 2015 11:23:21 -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: Fri, 20 Mar 2015 17:05:09 -0000

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.
> 
> > 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
> 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.
> 
> Greetings,
> 
> Stefan Winter