Re: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt - part 2

[<[e-mail]>]

Indeed, it is old stuff!
Can we consider that this part of text is not relevant to RFC4005 (but to any Diameter application) and could be removed from this spec without impact? I think that this point will be anyway covered by the dedicated draft on E2E security.

Regards,

Lionel

De : [e-mail] [mailto:[e-mail]] De la part de Glen Zorn
Envoyé : mercredi 11 juillet 2012 12:46
À : [e-mail]
Objet : Re: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt - part 2

On Wed, 2012-07-11 at 11:05 +0200, Benoit Claise wrote:
Dear all, Glen,

Two more points, part of the AD review (I needed a little bit of education before making those points, hence the part 2 in my review)

1. the NASREQ application is specified in RFC4005bis, but IANA points to RFC3588bis
See http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45
with an entry for Application id= 1, for NASREQ, with the reference [RFC-ietf-dime-rfc3588bis-33]

I understand the history: RFC3588 introduced this application id value 1 in the IANA Considerations section.
However, RFC3588bis, which will obsolete RFC3588, doesn't mention this application id (obviously, because it was assigned already).
So don't you believe that we should correct this and have, in the IANA Considerations section of http://tools.ietf.org/id/draft-ietf-dime-rfc4005bis-09.txt , a message basically expressing:
    http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45  should contain
             Application id= 1, for NASREQ, with the reference [RFC4005bis]

Obviously, I don't agree.  The value was registered in RFC 3588, and there is nothing to "correct" unless of course you insist, as does at least one IESG member, that the IANA references always point to the technical definition of the registered item (a position so untenable as to be absurd).




2.  In section 3.10 Accounting-Answer (ACA) Command



The same level of security MUST

   be applied to both the Accounting-Request and the corresponding

   Accounting-Answer message.  For example, if the ACR was protected

   using end-to-end security techniques then the corresponding ACA

   message MUST be protected in the same way; note, however, that the

   definition of such techniques is outside the scope of this document.
Note: this message about "The same level of security ..." is only available in that section

Sorry, I don't understand.


Why does this apply only to Accounting-Request and Accounting-Answer?

The answer to that question is likely lost in the mists of time [;-)] .  I surely don't remember why...


Or does it apply to all Request/Answer?

...

_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.