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

[Benoit Claise <[e-mail]>]

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]


2.  In section 3.10Accounting-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
Why does this apply only to Accounting-Request and Accounting-Answer?
Or does it apply to all Request/Answer?

Regards, Benoit.

> Dear all, Glen,
>
> Please find below the AD review of draft-ietf-dime-rfc4005bis-09.txt
>
> The document is in a good enough shape to be sent to IETF LC.
> Please consider my comments together with the other IETF LC comments.
>
> Glen, let me know if you plan on submitting a quick revision soon, or 
> if I should send THIS version to the IETF LC (which might lead to 
> redundant comment)
>
>
> - Some idnits
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-dime-rfc4005bis-09.txt
>    Miscellaneous warnings:
>    ----------------------------------------------------------------------------
>
>    == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
>       does not include the phrase in its RFC 2119 key words list.
>
>    Checking references for intended status: Proposed Standard
>    ----------------------------------------------------------------------------
>
>    == Missing Reference: 'BASE' is mentioned on line 219, but not defined
>
> I understand that this is a quote from RFC4005. To avoid the source of 
> confusion, here is a proposal
>
> OLD:
>        However, the presence of an
>        instance of the Acct-Application-Id AVP was required in RFC 4005,
>        as well:
>
>           The ACR message [BASE] is sent by the NAS to report its session
>           information to a target server downstream.
>
>           Either of Acct-Application-Id or Vendor-Specific-Application-Id
>           AVPs MUST be present.  If the Vendor-Specific-Application-Id
>           grouped AVP is present, it must have an Acct-Application-Id
>           inside.
> NEW:
>        However, the presence of an
>        instance of the Acct-Application-Id AVP was required in RFC 4005,
>        which quotes:
>
>           "The ACR message [BASE] is sent by the NAS to report its session
>           information to a target server downstream.
>
>           Either of Acct-Application-Id or Vendor-Specific-Application-Id
>           AVPs MUST be present.  If the Vendor-Specific-Application-Id
>           grouped AVP is present, it must have an Acct-Application-Id
>           inside."
>
> - One small improvement
> OLD:
>     o  The accounting model to be used is now specified.
>
> NEW
>     o  The accounting model to be used is now specified. See section 1.6
>
> - Expand on the first ASA occurrence
>
> - Add an point after [I-D.ietf-dime-rfc3588bis]
>
>     3.1.  AA-Request (AAR) Command
>
>         The AA-Request (AAR), which is indicated by setting the Command-Code
>         field to 265 and the 'R' bit in the Command Flags field, is used to
>         request authentication and/or authorization for a given NAS user.
>         The type of request is identified through the Auth-Request-Type AVP
>         [I-D.ietf-dime-rfc3588bis] The recommended value for most situations
>         is AUTHORIZE_AUTHENTICATE.
>
> - I could not find the meaning of * in, for example,
>
>                            [ CHAP-Auth ]
>                            [ CHAP-Challenge ]
>                          * [ Framed-Compression ]
>                            [ Framed-Interface-Id ]
>                            [ Framed-IP-Address ]
>                          * [ Framed-IPv6-Prefix ]
>                            [ Framed-IP-Netmask ]
>                            [ Framed-MTU ]
>                            [ Framed-Protocol ]
>                            [ ARAP-Password ]
>                            [ ARAP-Security ]
>                          * [ ARAP-Security-Data ]
>                          * [ Login-IP-Host ]
>                          * [ Login-IPv6-Host ]
>                            [ Login-LAT-Group ]
>                            [ Login-LAT-Node ]
>                            [ Login-LAT-Port ]
>                            [ Login-LAT-Service ]
>                          * [ Tunneling ]
>                          * [ Proxy-Info ]
>                          * [ Route-Record ]
>                          * [ AVP ]
> - 3.7.  Abort-Session-Request (ASR) Command
>
>     The Abort-Session-Request (ASR) message [I-D.ietf-dime-rfc3588bis]
>     may be sent by any server to the NAS providing session service, to
>     request that the session identified by the Session-Id be stopped.
>
> By "any Diameter server"?  like in section 3.3 btw.
>
> - IANA Considerations
> Do we need to change all the "4005" entries in 
> http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml into 
> "4005bis"?
> Or to be more correct, the new RFC id for 4005bis?
>
> - OLD
>     [RADIUSTypes]               IANA, "IANA Radius Attribute Values
>                                 Registry",<http://www.iana.org/
>                                 assignments/radius-types-3>.
>
> NEW:
>     [RADIUSTypes]               IANA, "IANA Radius Attribute Values
>                                 Registry",<http://www.iana.org/
>                                 assignments/radius-types>.
>
> ALTERNATE PROPOSAL
>     [RADIUSTypes]               IANA, "IANA Radius Attribute Values
>                                 Registry",<http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-1>.
>
> Regards, Benoit.
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime