Subject: Re: [ISSUE] Status-Server

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Dec 2008 11:03:48 +0100

Greg Weber wrote:
> * idnits says the boilerplate needs to be updated.

  Done.

> *  In section 3, I see: "Status-Server packets MAY include NAS-Identifier,
> one of NAS-IP-Address or NAS-IPv6-Address, and Reply-Message."
> This conflicts with the Table of Attributes in section 6 which indicates
> that Reply-Message cannot be included in Status-Server packets.

  The Status-Server packet shouldn't include a Reply-Message.  I've
updated the document.

> * Reply-Message can be included in Access-Accept, but not Acct-Response?
> That means the Verbose Query and Response example in section 7.3 works
> only for authentication servers and not accounting servers.  That seems like
> a discontinuity.

  Yes.  It's in line with existing implementations, and with practices
for Accounting-Response.  I wouldn't want this document to make it look
like Accounting-Response can now contain standard RADIUS attributes.

> * The Table of Attributes in section 6 indicates that Calling-Station-Id
> may be included Status-Server and Access-Accept packets.  This
> conflicts with RFC 2865 which disallows that attribute in Access-Accept.
> And, how would this attribute be populated in Status-Server packets
> where there is no associated calling station?

  The reference to Calling-Station-Id has been removed from the Table of
Attributes.

> * I would suggest removing all of section 5.  These topics seem related,
> but not germane to the purpose and scope of this doc.

  Possibly.  Are there other people who agree?

> * In section 4.1, I see "Robust implementations SHOULD accept any Response
> packet as a valid response to a Status-Server packet..."  That seems to be a
> pretty fundamental change to the RADIUS request/response model.  I would
> suggest removing that paragraph or changing it to a MAY.

  As per other reviews, I've updated that to say SHOULD accept
Access-Accept/Accounting-Response.  Other response types are NOT
RECOMMENDED.

> Small changes by section:
> ToC: Fix indent & missing title on 2.3.2
> Section 3: "MUST NOTE" -> "MUST NOT"
> Section 3.1: "is an CoA-ACK packet" -> "is a CoA-ACK packet."

  I've deleted that text.

> Section 4.3: "to start packets to start" -> "to start"
> Section 4.4: "may sent" -> "may be sent"
> Section 4.6: "along along" -> "along"

  Fixed.

> Section 4.6: "impement" -> "implement"
> Section 5.1: "has internal RADIUS server that proxy" ->
>   "has an internal RADIUS server that proxies"

  Fixed as per Alfred's review.

> Section 6: "table provide a guide" -> "table provides a guide"
> 
> Small global changes:
> "it's" -> "its" (6 times)
> "wide-spread" -> "widespread" (2 times)

  Fixed.

> "inter-operable" -> "interoperable" (1 time)

  Fixed.

> "use-case" -> "use case" (3 times)

  Fixed.

> "pro-actively" -> "proactively" (1 time)

  Deleted.

> "re-use" -> "reuse" (3 times)

  Fixed.

> "coa" -> "CoA" (2 times)

  Deleted.

> "16-octet" -> "16 octet" (3 times)

  Fixed.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Dec 2008 09:02:08 -0800

> > but not germane to the purpose and scope of this doc.

I can see removing all of Section 5, though I would want the material in
Section 5.2 to end up somewhere (maybe the RADIUS over TCP doc). 

Section 5.1 does seem tangential to the goal of describing how Status-Server
is used.  

Section 5.2 does seem relevant, since it clarifies the use/limitations of
Status-Server over reliable transport.  This section could just as easily
go in the RADIUS over TCP document, though. 

At IETF 73, we talked about removing references to CoA (Section 5.3).