RE: Issue 226: RFC 3576bis and Renumbering

[Bernard Aboba <bernard_aboba@hotmail.com>]

> s/so that the User-Name may not be/because the User-Name may not be/

Got it. 
 
> > Where the Acct-Session-Id attribute is not present in a CoA-Request
> > or Disconnect-Request, it is possible that the User-Name or
> > Chargeable-User-Identity attributes will not be sufficient to
> > uniquely identify the session (e.g. if the same user has multiple
> > sessions on the NAS). As a result, the Called-Station-Id, Calling-
> > Station-Id, NAS-Port, NAS-Port-Id and Acct-Multi-Session-Id
> > attributes MAY be used for session identification in addition.
> 
> s/MAY be used for session identification in addition./MAY be used as
> additional session identification./
 
Here is a rewritten paragraph:
 
Where the Acct-Session-Id or Acct-Multi-Session-Id attributes are not present in  a CoA-Request or Disconnect-Request, it is possible that the User-Name or Chargeable-User-Identity attributes will not be sufficient to uniquely identify the session (e.g. if the same
user has multiple sessions on the NAS, or the privacy NAI is used). As a result, the Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id attributes MAY be used as additional session identification.
 
> > [Note 6] Support for the Service-Type of "Authorize Only" is OPTIONAL
> > on the NAS and RADIUS server. A NAS supporting the "Authorize Only"
> > Service-Type value within a CoA-Request packet MUST respond with a
> > CoA-NAK containing a Service-Type Attribute with value "Authorize
> > Only", and an Error-Cause Attribute with value "Request Initiated".
> > The NAS then sends an Access-Request to the RADIUS server with a
> > Service-Type Attribute with value "Authorize Only". This Access-
> > Request SHOULD contain the NAS attributes from the CoA-Request, as
> > well as the session attributes from the CoA-Request legal for
> > inclusion in an Access-Request as specified in [RFC2865], [RFC2868], 
> > [RFC2869] and [RFC3162]. As noted in [RFC2869] Section 5.19, a
> > Message-Authenticator attribute SHOULD be included in an Access-
> > Request that does not contain a User-Password, CHAP-Password, ARAP-
> > Password or EAP-Message Attribute. The RADIUS server should send
> > back an Access-Accept to (re-)authorize the session or an Access-
> > Reject to refuse to (re-)authorize it.
> > 
> > A NAS that does not support the Service-Type Attribute with the value
> > "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
> > including no Service-Type Attribute; an Error-Cause Attribute with
> > value "Unsupported Service" MAY be included.
> > 
> > [Note 7] The State Attribute is available to be sent by the RADIUS
> > server to the NAS in a CoA-Request packet and MUST be sent unmodified
> > from the NAS to the RADIUS server in a subsequent ACK or NAK packet.
> > If a Service-Type Attribute with value "Authorize Only" is included
> > in a CoA-Request then a State Attribute MUST be present, and MUST be
> > sent unmodified from the NAS to the RADIUS server in the resulting
> > Access-Request sent to the RADIUS server, if any. The State
> > Attribute is also available to be sent by the RADIUS server to the
> > NAS in a CoA-Request that also includes a Termination-Action
> > Attribute with the value of RADIUS-Request. If the client performs
> > the Termination-Action by sending a new Access-Request upon
> > termination of the current session, it MUST include the State
> > Attribute unchanged in that Access-Request. In either usage, the
> > client MUST NOT interpret the Attribute locally. A CoA-Request
> > packet must have only zero or one State Attribute. Usage of the
> > State Attribute is implementation dependent.
> > 
> > [Note 8] Where included within a CoA-Request, these attributes
> > represent a renumbering request. Since these attributes are not used
> > for session identification, they MUST NOT be included within a
> > Disconnect-Request. Note that renumbering may not be possible in all
> > situations. For example, in order to change an IP address on receipt
> > of a changed Framed-IP-Address address, IPCP re-negotiation could be
> > required, which is not supported by all PPP implementations.
> 
> It strikes me that the large number and substantial nature of these notes
> suggests that they be incorporated elsewhere in the normative text of the
> document, rather as footnotes to the Table of Attributes. I think it would
> substantially enhance readability of the document. 
 
I will move Notes 6 and 7 into the main text.