[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ISSUE] Status-Server
- To: "radext mailing list" <radiusext@ops.ietf.org>
- Subject: [ISSUE] Status-Server
- From: "Greg Weber" <gdweber@gmail.com>
- Date: Mon, 24 Nov 2008 11:23:15 -0500
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=JTSg6O/PRKpe4ps/TSEaUAQ3c5v7myHZEd20AriA4qgGLXc1ce7VU7NZ223DDLWHVx +99xBl8vlUJOetuw1fcZzMZOCYxXNSQL76EhuWBk2mCfo3giRP6OpmZZkgsN5HoxLuv7 jLtJlPi2IWiXZz+1xDBgfAD52oRkmKy3o3A+g=
Status-Server comments
Submitter name: Greg Weber
Submitter email address: gdweber@gmail.com
Date first submitted: November 24, 2008
Reference: n/a
Document: draft-ietf-radext-status-server-02.txt
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: various
Here are some editorial comments on the Status-Server doc currently in
WG last call.
* idnits says the boilerplate needs to be updated.
* 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.
* 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.
* 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?
* I would suggest removing all of section 5. These topics seem related,
but not germane to the purpose and scope of this doc.
* 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.
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."
Section 4.3: "to start packets to start" -> "to start"
Section 4.4: "may sent" -> "may be sent"
Section 4.6: "along along" -> "along"
Section 4.6: "impement" -> "implement"
Section 5.1: "has internal RADIUS server that proxy" ->
"has an internal RADIUS server that proxies"
Section 6: "table provide a guide" -> "table provides a guide"
Small global changes:
"it's" -> "its" (6 times)
"wide-spread" -> "widespread" (2 times)
"inter-operable" -> "interoperable" (1 time)
"use-case" -> "use case" (3 times)
"pro-actively" -> "proactively" (1 time)
"re-use" -> "reuse" (3 times)
"coa" -> "CoA" (2 times)
"16-octet" -> "16 octet" (3 times)
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>