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

[Benoit Claise <[e-mail]>]

Glen,
> 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).
So right now, "application id = 1" points to RFC 3588bis, which is 
neither the RFC that registered the value (RFC3588), nor the NASREQ 
specification (RFC4005bis), so the pointer to RFC 3588bis seems pretty 
useless to me.
Anyway, I sent a private email to Michelle Cotton a few days ago (and I 
copied her again on this email thread).
My advice is to simply follow the IANA guidance.

Regards, Benoit.
>
>>
>>
>> 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?
>
> ...
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime