[radext] Fwd: RE: non-opsdir review of draft-ietf-radext-dynamic-discovery

[Stefan Winter <[e-mail]>]

Here is the follow-up ...


-------- Original Message --------
Subject: RE: non-opsdir review of draft-ietf-radext-dynamic-discovery
Date: Mon, 24 Feb 2014 13:40:53 -0500
From: ietfdbh <[e-mail]>
To: 'Stefan Winter' <[e-mail]>

Hi Stefan,

Yes. It is ok to send this to the radext list.
You can also post the following comments, but I am not subscribed to radext,
so I will not follow subsequent discussions.
Here are a few comments, inline, regarding your reply.

David Harrington
[e-mail]
[phone]

> -----Original Message-----
> From: Stefan Winter [mailto:[e-mail]]
> Sent: Monday, February 24, 2014 8:16 AM
> To: ietfdbh; [e-mail]
> Subject: Re: non-opsdir review of draft-ietf-radext-dynamic-discovery
[...]

> Well, one document has, it's the reference [I-D.ietf-radext-nai] "The
> Network Access Identifier" (which is normative).

Ah, you're right. I looked for references to terminology in the terminology
section.
It would be helpful to list, in the terminology section, which terms are
used and which references define the terms.
Something like "[draft-nai] defines the following terminology related to
identifiers: nai, realm, consortium"
That way readers don't need to hunt through all your normative references to
find the definitions.
I would not have necessarily thought to read a work-in-progress draft on NAI
to find the term realm.
Keep in mind you are trying to get people to buy into your proposal; if you
make it hard to read and understand, readers will just walk away.
> 
> Many would think that referencing RFC4282 would be most natural when
> talking about realms, as it is the current RFC on that topic. However,
> it has many acknowledged errors, and [I-D.ietf-radext-nai] is an
> attempts to fix them; so I'd rather point to current work instead, and
> accept that our document gets delayed by a pending normative reference.

It might be useful to point to both and include an explanation of why you
include the I-D.
That way, anybody reviewing the draft (including potential implementers and
IESG) will benefit from this additional information.
When the ID becomes an RFC, you can change the reference.

> 
> I take your point though that [I-D.ietf-radext-nai] is referenced very
> late in the document, and that it should rather be introduced in the
> Introduction.
> 
> I've done that in my -11-to-be now. The new text is:
> 
> 
> "1.  Introduction
> 
>    RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP,
>    RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers
>    (clients, servers).
> 
>    Where more than one administrative entity collaborates for RADIUS
>    authentication of their respective customers (a "roaming
>    consortium"), the Network Access Identifier (NAI)
>    [I-D.ietf-radext-nai] is the suggested way of differentiating users
>    between those entities; the part of a username to the right of the @
>    delimiter in a NAI is called the user's "realm".  Where many realms
>    and RADIUS forwarding servers are in use, the number of realms to be
>    forwarded and the corresponding number of servers to configure may be
>    significant.  Where new realms with new servers are added or details
>    of existing servers change on a regular basis, maintaining a single
>    monolithic configuration file for all these details may prove too
>    cumbersome to be useful.
> 
>    Furthermore, in cases where a roaming consortium consists of
>    independently working branches (e.g. departments, national
>    subsidiaries), each with their own forwarding servers, and who add or
>    change their realm lists at their own discretion, there is additional
>    complexity in synchronising the changed data across all branches."
> 
So now that I better understand the purpose of realms, isn't the Diameter
standard designed to handle collaborating entities for authentication?
(obviously, not being a RADIUS, expert, neither am I a Diameter expert.)
> 
[...]
> > I would expect better interoperability if this document was something
> where
> > the procedures were more nailed down.
> 
> Point taken. In my defense though :-) :
> 
> This is a document where global interop is not a requirement. A roaming
> agreement requires much more than technical discoverability; there's
> paperwork attached to it. Service contracts, backoffice compensations,
> procedures, ...
> 
> So long as one consortium can settle on one deployment option, they will
> be able to interoperate based on that choice; this is the scope we're
> looking at here.
> 
> The service contract for the consortium would nail down which CAs are
> trustworthy anchors; which properties a certificate needs to have, etc.
> 

I suggest you include a "Operations and Manageability Considerations"
section, and explain the expected applicability.
Your explanation here would be useful to other reviewers.

> Plus, this is Expermental  :-) ; an abundance of options is maybe not
> the best but I'd hope it is tolerable at this stage. If one specific
> validation mechanism or DNS form prevails in real deployment, the
> document can evolve into Standards Track and become more narrow.
> 
You are, however, asking IANA to register assignments.
And I think you are using non-experimental registries.
And those assignments are not likely to be unassigned at the end of the
experiment.

This raises an additional point.
When I was on the IESG, there was a push (by people still on the IESG) to
require that experimental RFCs:
1) clearly state that the proposal is a proposed experiment,
2) explain what communities are expected to participate in the experiment,
3) explain the expected duration of the experiment,
4) describe the expected information to be gathered form the experiment,
5) describe "success" factors for the experiment,

There might be an RFC that more definitively states those (and possibly
other) requirements. Check with your AD.

> > This document deals with DNS SRV records, but there is no mention of
> > RFC6335, the BCP for SRV and Transport registrations. I rather expected
> that
> > it might reference the BCP someplace. It might help reviewers if you
> > describe whether your proposal follows the BCP.
> 
> The proposed names conform to section 5.1 of RFC6335.
> 
> I noticed now (after realising that RFC6335 exists ;-) ) that my notion
> of service label = _ + "service name" and so what's requested at IANA is
> not a service label, but the underlysing service name. I've corrected
> the IANA Considerations section and added all required information as
> per section 8.1.1 of RFC6335.
> 
> This is the new text of the corresponding subsection:
> 
> "   This document reserves the use of the "radiustls" and "radiusdtls"
>    service names.  Registration information as per [RFC6335] section
>    8.1.1 is as follows:
> 
>       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 Editor Note: please insert the RFC number of this
>       document.  The protocol does not use broadcast, multicast or
>       anycast communication."
> 

Radius/tls and radius/dtls are actually defined in documents other than this
one.
THIS document is about radius discovery using a specific approach and
algorithms, for specific environments.
This document is also experimental, and might never be published as an RFC.
So it concerns me to have radiustls and radiusdtls names reserved by this
document.

Might it be a good idea to separate this draft into two drafts?
	1) A standards-track document for registering RADIUS services in
DNS, a simple DNS discovery of radiustls and radiusdtls servers,
	2) An experimental draft for explaining how to go further to
discover realms, especially in the case of roaming consortia?
I'm not quite sure where one thing ends and the other starts.

One nit that I noticed in my initial review.
You use an example of very.bad.example
While cute, I did not understand whether this was simply cuteness in names,
or actually implying that this particular example was an example of a very
bad practice. I finally decided it was just cuteness, but ambiguity is not a
good thing in standards-related documents ;-)
I expect you could find better examples.

Hope this helps; you can forward this to the list, or not, at your
discretion.

dbh