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

[Glen Zorn <[e-mail]>]

On Tue, 2012-07-10 at 16:46 +0200, Benoit Claise wrote:

> 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


Rereading this, I don't know what confusion you mean.  It seems to be
fine English, pretty clear, and it doesn't seem like the change you
suggest is likely to unconfuse ID-nits.  What am I missing?


> 
> 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.