In the description of the Operator-Name Attribute (section 3.1), the discussion of the encoding of a name in the "REALM" namespace is incomplete, at best. First, there is no discussion of the steps (if any) to be taken if the toASCII conversion fails in the case of a realm name containing non-ASCII characters. In any case, however, it is not possible to encapsulate a maximum-length FQDN in a RADIUS attribute because the maximum length of a RADIUS Attribute data payload is 253 octets, while the maximum length of an ASCII FQDN is 255 octets. Furthermore, due to the addition of the ACE prefix(es) as a result of the toASCII conversion process, the actual length of a converted realm name may be considerably less than 253 octets. The conventional way to deal with type of problem in RADIUS would be to split the offending string up into multiple attributes; however, the formatting of the Operator-Name attribute into distinct sub-fields would seem to preclude the use of that technique. I suggest that (in order of preference) a) the Operator-Name Attribute be split into separate Operator-Namespace and Operator-Name Attributes with instructions included on handling too-long FQDNs b) the attribute be redefined in terms of the new Extended RADIUS Attributes (http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribut es-03.txt) or at the least c) text be added noting the actual restrictions on realm name length Section 3.3, paragraph 2 doesn't make a lot of sense to me: suggest rewriting it in less florid if more precise language. For example, something like this: "In order to enable the on-demand mid-session location delivery method, the RADIUS server MUST return an instance of the Requested-Location-Info Attribute with the 'FUTURE_REQUESTS' flag set and instances of the Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Attributes in the Access-Accept message for the session. Upon receipt of a CoA-Request message containing a Service-Type Attribute with value "Authorize Only" for the same session, the NAS MUST include location information and echo the previously received Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Attributes in the subsequent Access-Request message." Section 4.2 says: Length: >= 21 String: This field is at least two octets in length, and the format is shown below. The data type of this field is string. Suggestion: change "at least two" to "at least 19". Later in the same section, it says: Method (variable): Describes the way that the location information was determined. The values are registered with the 'method' Tokens registry by RFC 4119. The data type of this field is a string. Does "registered with the 'method' tokens" mean "along with the token values in the same registry" or something else? I _think_ that what the authors are trying to say is "This field MUST contain the value of exactly one IANA-registered 'method' token [RFC4119]." If so, maybe they should. Section 4.2.1 says "The location format is based on the encoding format defined in Section 3.1 of [RFC4776] whereby the first 3 octets (i.e., the code for this DHCP option, the length of the DHCP option, and the 'what' element are not included) are not put into the Location field of the above-described RADIUS Location-Data Attribute." I don't really understand: does this mean that 'the location format is identical to that defined in RFC 4776 with the exception that the first three octets are omitted'? In any case, RFC 4776 say in the last paragraph of section 1: The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be used if the civic address option exceeds the maximum DHCPv4 option size of 255 octets. My comments on are similar to those on the Operator-Name Attribute above; this case is a little more complicated, due to the use of the Index field to associate this attribute with the corresponding Location-Information attribute (there seems to be an implicit assumption that these always come in pairs). Section 4.3 says: "Implementations SHOULD treat this attribute as undistinguished octets." In context, this statement doesn't make sense in at least two ways. First, I have no idea how any implementation can treat an entire attribute as undistinguished octets, since at least the Type and Length fields have to be distinguished. Maybe the authors mean that the String field of the attribute should be treated in this way, but that doesn't seem reasonable, either, because that field is itself formatted into two distinct fields. Section 4.4 says "The Basic-Location-Policy-Rules Attribute MAY be sent in an Access-Request, Access-Accept, an Access-Challenge, an Access-Reject, a Change-of-Authorization and in an Accounting-Request message." but RFC 2865 says (section 2, paragraph 7) "If any condition is not met, the RADIUS server sends an "Access-Reject" response indicating that this user request is invalid. If desired, the server MAY include a text message in the Access-Reject which MAY be displayed by the client to the user. No other Attributes (except Proxy-State) are permitted in an Access-Reject." This being the case, it seems like there should be an "Updates: 2865" in the first page header of the draft. The Location-Capable (section 4.6) attribute can take only a "True" value (presumably the lack of client ability would be signified by the absence of the Location-Capable Attribute in the Access-Request). This puzzles me a bit: isn't it possible that a NAS might be capable of discovering (& therefore, communicating) one or a few type of location data and not others? For example, it seems rather likely that a dial-up NAS might be capable of conveying its own civic location but not the geospatial location of the remote node. I guess what I'm asking is if there isn't a need for a little greater granularity here. The discussion of the Requested-Location-Info Attribute in section 4.7 is remarkably soft and fluffy, attributing such things as "wants" and "desires" to servers and clients. To the best of my knowledge, software does not (yet) display needs, let alone desires. This would just be a little annoying except that the warm fuzziness spills over into the actual specification of what are presumably requirements. For example: If the RADIUS server wants to dynamically decide on a per-request basis to ask for location information from the RADIUS client then the following cases need to be differentiated. If the RADIUS client and the RADIUS server have agreed out-of-band to mandate the transfer of location information for every network access authentication request then the processing listed below is not applicable. o If the RADIUS server requires location information for computing the authorization decision and the RADIUS client does not provide it with the Access-Request message then the Requested-Location- Info Attribute is attached to the Access-Challenge with a hint about what is required. Two cases can be differentiated: 1. If the RADIUS client sends the requested information then the RADIUS server can process the location-based attributes. 2. If the RADIUS server does not receive the requested information in response to the Access-Challenge (including the Requested-Location-Info Attribute) then the RADIUS server may respond with an Access-Reject message with an Error-Cause Attribute (including the "Location-Info-Required" value). In the case of #1, "the RADIUS server can process the location-based attributes". This seems fairly obvious, but just because it _can_ doesn't mean that it _will_; it might not (presumably based upon its "desires" ;-). Must the server process the location information? If so, the document should say so. Similarly in case #2, "the RADIUS server may respond with an Access-Reject message with an Error-Cause Attribute (including the "Location-Info-Required" value)." If it "may" then it may also not; just guessing (since there are supposedly only two cases and the information is stated to be required in order to process the authorization request) it seems to me that the authors really mean "MUST" in both cases but that is not clear at all. o If the RADIUS server would like location information in the Accounting-Request message but does not require it for computing an authorization decision then the Access-Accept message MUST include a Required-Info Attribute. This is typically the case when location information is used only for billing. The RADIUS client SHOULD attach location information, if available, to the Accounting-Request (unless authorization policies dictate something different). Once again the server exhibits desire, but this paragraph begs another question: if the data referred to by the Requested-Location-Info Attribute is actually required and the Required-Info Attribute signifies data that is optional, why are they named the way they are? Change "8.3. New Registry: Location Capable Attribute" to "8.3. New Registry: Location-Capable Attribute". Many references are out of date or incorrect. Given that Bernard is a co-author, it may be a bit excessive to mention him (thrice!) in the Acknowledgements section _and_ in the Contributors section as well ;-). In section A.1, paragraph 1 change "This section discusses the privacy implication for making location information available to other entities." to "This section discusses the privacy implications of making location information available to other entities." Last but not least, this draft fairly universally violates several of the guidelines given in http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt, in particular those regarding the use of tags to associate different attributes (called "Index" in this document) and the creation of "complex" attributes. I realize that the RADIUS design guidelines document is just an Internet-Draft, but it is a radext WG document & has been under construction for some period of time. More important than the standardization status of the document is the question of whether the guidelines make sense; if so, then it may not be such a good idea to so completely ignore them; if not, then maybe radext should rethink this work item (especially since a co-chair of that WG is also a co-author of the document under review). _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf