Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hi Dave,

Please see below.

Regards,

Lionel

> -----Message d'origine-----
> De : David B. Nelson [mailto:[e-mail]]
> Envoyé : mardi 6 septembre 2016 17:22
> À : MORAND Lionel IMT/OLN
> Cc : kathleen moriarty ietf; Alissa Cooper; draft-ietf-radext-ip-port-radius-
> [e-mail]; [e-mail]; IESG; [e-mail]
> Objet : Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-
> ext-11: (with DISCUSS and COMMENT)
> 
> Lionel wrote:
> 
> > My understanding is that, when defining authorization type attributes
> > that are use over RADIUS, it is not deemed required to define the
> > specific use of these attributes nor the error handling.
> 
> Yes and no.  While attributes can be re-used in multiple applications and use
> cases, the *semantics* of the authorization needs to be unambiguous.
> Remember, RADIUS doesn't have the notion of applications, so the meaning of
> attributes needs to be idempotent, if good interoperability to to be achieved.

[LM] I agree. Especially on the semantic issue.

> 
> > As for other AAA documents, this draft is not specifying a specific
> > procedure or a new protocol application. It is just about defining
> > attributes that can be used in the use case described in this document
> > but also in any other solution that would see advantage to reuse these
> attributes.
> 
> Yes, but see above.

[LM] ok.

> 
> > The main point of this document is to ensure that the definitions of
> > these attributes are correct (type, length, value), unambiguous and
> > describe in which messages they can appear.
> 
> The definition of RADIUS attributes also includes their semantics, not just their
> syntax.
> 
> > The exact behavior of the client/server using these attributes is
> > often left out of this kind of document. It is up to the specification
> > describing the implementation the clients and/or servers using these
> > attributes to define this error handling.
> 
> I disagree.  Leaving out semantics and client/server behavior is not traditional
> for RADIUS and is likely to lead to poor interoperability.

[LM] I think that there is what it could be and what it is. As I said, I agree with your comment on the format and the semantic of the attributes. But on client/server behavior and error handling, you can check for instance with RFC7268 and RFC6911 (other standards track RFCs defining RADIUS attributes) that these aspects are not always addressed. It depends on who is the real "client" of the specification. In the present case, the attributes are only used for configuration or reporting, not strictly related to the authorization process.   
Now, if authors want to address these points in the draft, I will be fine. But I'm not convinced it is required to be published as RFC.

> 
> Regards,
> 
> Dave Nelson

_________________________________________________________________________________________________________________________

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.