Re: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09

Hi Stefan, Jouni,

I'm ok with the general content of this draft.
But, just after a brief review of the last version, I have the following comments/questions.

In Section 2.1.1.1. Registration of Application Service and Protocol Tags

   This specification defines three S-NAPTR service tags:

   +-----------------+-----------------------------------------+
   | Service Tag     | Use                                     |
   +-----------------+-----------------------------------------+
   | aaa+auth        | RADIUS Authentication, i.e. traffic as  |
   |                 | defined in [RFC2865]                    |
   | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
   | aaa+acct        | RADIUS Accounting, i.e. traffic as      |
   |                 | defined in [RFC2866]                    |
   | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
   | aaa+dynauth     | RADIUS Dynamic Authorisation, i.e.      |
   |                 | traffic as defined in [RFC5176]         |
   +--------------- --+-----------------------------------------+

                      Figure 1: List of Service Tags

[LM] For historical reasons, "aaa" is already assigned to Diameter. The proposed values for RADIUS related Application Service Tags are not wrong per se but it could be misleading... What about using "RADIUS+" instead of "aaa+" to avoid such possible confusion? 

[LM] I don't know if it is something commonly in use but I was wondering if it would be also suitable to define a service tag for Auth+Acc when both types of traffic are sent to the same server. 

In Section 3.1. Applicability

   Dynamic server discovery as defined in this document is only
   applicable for AAA transactions where a RADIUS entity which acts as a
   forwarding server for one or more realms receives a request with a
   realm for which it is not authoritative, and which no explicit next
   hop is configured.  It is only applicable for

   a.  new user sessions, i.e. for the initial Access-Request.
       Subsequent messages concerning this session, for example Access-
       Challenges and Access-Accepts use the previously-established
       communication channel between client and server.

   b.  RADIUS DynAuth server discovery

[LM] I think that the case for initial Accounting-Request is missing. Sorry if this point was discussed earlier on the mailing list.

Regards,

Lionel

-----Message d'origine-----
De : radext [mailto:radext-bounces@ietf.org] De la part de Jouni Korhonen
Envoyé : mardi 14 janvier 2014 09:47
À : radext@ietf.org
Cc : radext-chairs@tools.ietf.org; draft-ietf-radext-dynamic-discovery@tools.ietf.org
Objet : Re: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09

The WGLC ended recently for this document. Zero reviews or comments.
If folks think the document is ready, at least express that on the
list. I'll extend the WGLC by few weeks shortly.

In a meanwhile I have requested reviews from various externals
interest groups (secdir, DNS ppl etc).

- Jouni & Mauricio

On Dec 30, 2013, at 7:00 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

> Folks,
> 
> This email starts a two week WGLC for the
> draft-ietf-radext-dynamic-discovery-09.
> The WGLC ends 13th Jan 2014.
> 
> Please, review the document, submit your
> comments to the mailing list and also enter
> them into Issue Tracker.
> 
> - Jouni & Mauricio
> 
> 

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.