Re: [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

Stefan Winter <> Fri, 20 March 2015 08:52 UTC

Return-Path: <>
Received: by (Postfix, from userid 65534) id 441581A8958; Fri, 20 Mar 2015 01:52:51 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id 20B581A6F02 for <>; Fri, 20 Mar 2015 01:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.709
X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y_AxGHwHYTXN for <>; Fri, 20 Mar 2015 01:52:49 -0700 (PDT)
Received: from ( [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA3C21A877C for <>; Fri, 20 Mar 2015 01:52:48 -0700 (PDT)
Received: from ( [IPv6:2001:a18:1:8::155]) by (Postfix) with ESMTPS id B392B4101D; Fri, 20 Mar 2015 09:52:46 +0100 (CET)
Message-ID: <>
Date: Fri, 20 Mar 2015 09:52:41 +0100
From: Stefan Winter <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
OpenPGP: id=8A39DC66; url=
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L7OWSVNnQhN1n4kISwXa9CNsjMG8KdQv6"
Archived-At: <>
X-Mailman-Approved-At: Fri, 20 Mar 2015 11:23:20 -0700
Subject: Re: [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-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Mar 2015 08:52:51 -0000


two comments:
> First, in the S-NAPTR Application Service Tags subregistry of the
> Straightforward-NAPTR (S-NAPTR) Parameters registry located at:
> 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:
>       Service Name: radiustls; radiusdtls
>       Transport Protocols: TCP, UDP
>       Assignee: IESG <>
>       Contact: IETF Chair <>
>       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 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.


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