[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" <[e-mail]>]

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, [e-mail] 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 <[e-mail]>
> > >
> > > Contact: IETF Chair <[e-mail]>
> > >
> > > 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
>