Carrying Location Objects in RADIUS and Diameter
draft-ietf-geopriv-radius-lo-24

[Ballot discuss]
Section 4.5 (Page 27): The description of the "Integer" field in the Location-Capable Attribute does not make explicit that the contents of the field is a bit field representing capabilities.  The description should be edited to match the description of the "Integer" field in the Requested-Loction-Info Attribute (section 4.7).

Section 4.6 (Page 30): If I understand the description of the Location-Capable Attribute correctly, in figure 6 the RADIUS Client would indicate some set of location capabilities in the Location-Capable attribute in the Access-Request message, and the RADIUS Server selects a subset of those capabilities in the Requested-Location-Info Attribute in the Access-Challenge message.  Figure 6 should include an example of the capabilities of the Radius Client in the Access-Request message, to be consistent with the indication of the capabilities in the Access-Challenge message.

[Ballot discuss]
Section 4.5 (Page 27): The description of the "Integer" field in the Location-Capable Attribute does not make explicit that the contents of the field is a bit field representing capabilities.  The description should be edited to match the description of the "Integer" field in the Requested-Loction-Info Attribute (section 4.7).

Section 4.6 (Page 30): If I understand the description of the Location-Capable Attribute correctly, in figure 6 the RADIUS Client would indicate some set of location capabilities in the Location-Capable attribute in the Access-Request message, and the RADIUS Server selects a subset of those capabilities in the Requested-Location-Info Attribute in the Access-Challenge message.  Figure 6 should include an example of the capabilities of the Radius Client in the Access-Request message, to be consistent with the indication of the capabilities in the Access-Challenge message.

[Ballot comment]
Section 4.4 (page 23): Text describing "String" in the Basic-Location-Policy_Rules Attribute is inconsistent: use "Flags" or "Flag" consistently; delete spurious "'" in "Flag'"; suggest (for consistency) replacing "The Flag' field" with "This field..."

Section 6 (page 37): A pointer to the rules for interpreting the table of data types and flag rules would be helpful.

[Ballot discuss]
I would have appreciated an overarching comment on the format of the TLVs you use so that it was clear whether the Length includes the Type and Length fields.

I find that in 4.1 for the Operator-Name Attribute we have
  Length:
      >= 5
Yet, Type is 1 byte, Length is 1 byte, and we see
  Text:
      This field is at least two octets in length
(which looks like >= 4 to me with the Type and Length included)

OTOH, in section 4.2 for the Location-Information Attribute we have a statement that
  Length:
      >= 21
and I see that we have
      Index (16 bits)
      Code (8 bits)
      Entity (8 bits)
      Sighting Time (64 bits)
      Time-to-Live (64 bits)
      Method (variable) [I think this is at least 8 bits]
Total at least 168 bits = 21 bytes.
So the Type and Length are not included.

Then in 4.3 for Location-Data Attribute
  Length:
      >= 21
This is clearly wrong since
  String:
      This field is at least two octets in length

And in 4.4 for Basic-Location-Policy-Rules Attribute
  Length:
      >= 12
where
  String:
      This field is at least 8 octets in length
Neither 8 nor 10 is equal to 12
But anyway, examining the contents of String yields
  Flag (16 bits):
  Retention Expires (64 bits):
  Note Well (variable):
That is at least 80 bits or 10 octets.
It is unclear whether the Note Well field may be empty.

Sections 4.5 and 4.6 imply the Type and Length are included.

IANA questions/comments:

- In Action #2, are values 0x00-0x29 and 0xFF available for
assignment? If so, what's the registration procedure?


Action #1:

Upon approval of this document, IANA will make the following
assignments in the "Radius Attribute Types" registry at
http://www.iana.org/assignments/radius-types

Value Description Reference
-------- | --------------------------------------- | ---------
TBD-1 | Operator-Name | [RFC-geopriv-radius-lo-23]
TBD-2 | Location-Information | [RFC-geopriv-radius-lo-23]
TBD-3 | Location-Data | [RFC-geopriv-radius-lo-23]
TBD-4 | Basic-Location-Policy-Rules | [RFC-geopriv-radius-lo-23]
TBD-5 | Extended-Location-Policy-Rules | [RFC-geopriv-radius-lo-23]
TBD-6 | Location-Capable | [RFC-geopriv-radius-lo-23]
TBD-7 | Requested-Location-Info | [RFC-geopriv-radius-lo-23]

Note: all values from the 126-191 range.


Action #2:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/radius-types

Registry Name: Operator Namespace Identifier for Attribute TBD-1
Reference: [RFC-geopriv-radius-lo-23]
Registration Procedures: Expert Review (for 0x34 - 0xFE)
Initial contents of this sub-registry will be:

+----------+--------------------+------------------------------------+
|Identifier| Operator Namespace | Contact Person | Reference
| | Token | |
+----------+--------------------+------------------------------------+
| 0x30 | TADIG | TD.13 Coordinator | [RFC-geopriv-radius-lo-23]
| | | (td13@gsm.org) |
| 0x31 | REALM | IETF O&M Area Directors | [RFC-geopriv-radius-lo-23]
| | | (ops-ads@ietf.org) |
| 0x32 | E212 | ITU Director | [RFC-geopriv-radius-lo-23]
| | | (tsbdir@itu.int) |
| 0x33 | ICC | ITU Director | [RFC-geopriv-radius-lo-23]
| | | (tsbdir@itu.int) |
+----------+--------------------+------------------------------------+


Action #3:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/radius-types

Registry Name: Location Profile code for Attribute TBD-2
Reference: [RFC-geopriv-radius-lo-23]
Registration Procedures: Expert Review

Initial contents of this sub-registry will be:

Value | Location Profile | Reference
0 | Civic locations | [RFC-geopriv-radius-lo-23]
1 | Geospatial location | [RFC-geopriv-radius-lo-23]
2-255 | Unassigned |


Action #4:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/radius-types

Registry Name: Location-Capable Attribute for TBD-6
Reference: [RFC-geopriv-radius-lo-23]
Registration Procedures: Expert Review

Initial contents of this sub-registry will be:

+----------+----------------------+
| Value | Capability Token | Reference
+----------+----------------------+
| 1 | CIVIC_LOCATION | [RFC-geopriv-radius-lo-23]
| 2 | GEO_LOCATION | [RFC-geopriv-radius-lo-23]
| 4 | USERS_LOCATION | [RFC-geopriv-radius-lo-23]
| 8 | NAS_LOCATION | [RFC-geopriv-radius-lo-23]
+----------+----------------------+


Action #5:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/radius-types

Registry Name: Entity Types for Attribute TBD-4
Reference: [RFC-geopriv-radius-lo-23]
Registration Procedures: Expert Review

Initial contents of this sub-registry will be:

Value | Entity Types | Reference
0 | user device location | [RFC-geopriv-radius-lo-23]
1 | RADIUS client location | [RFC-geopriv-radius-lo-23]
2-255 | Unassigned |

Action #6:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/radius-types

Registry Name: Privacy Flags for Attribute TBD-4
Reference: [RFC-geopriv-radius-lo-23]
Registration Procedures: Expert Review

Initial contents of this sub-registry will be:

Value | Privacy Flags |
0 | Retransmission allowed | [RFC-geopriv-radius-lo-23]


Action #7

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/radius-types

Registry Name: Requested-Location-Info for TBD-6
Reference: [RFC-geopriv-radius-lo-23] section 8.6
Registration Procedures: Expert Review

Initial contents of this sub-registry will be:
+----------+----------------------+
| Value | Capability Token |
+----------+----------------------+
| 1 | CIVIC_LOCATION | [RFC-geopriv-radius-lo-23]
| 2 | GEO_LOCATION | [RFC-geopriv-radius-lo-23]
| 4 | USERS_LOCATION | [RFC-geopriv-radius-lo-23]
| 8 | NAS_LOCATION | [RFC-geopriv-radius-lo-23]
| 16 | FUTURE_REQUESTS | [RFC-geopriv-radius-lo-23]
| 32 | NONE | [RFC-geopriv-radius-lo-23]
+----------+----------------------+

We understand the above to be the only IANA Actions for this document.

[Ballot comment]
This COMMENT is based on the AAA-Doctor review by David Nelson.

I have cleared a previous DISCUSS that was raising a number of concerns.

1. One of them was mentioning that this document needs at the very least an IESG Note calling attention to the fact that certain of the RADIUS attributes fail to meet either the letter or spirit of the RADIUS Design Guidelines as to what may properly constitute an "opaque" attribute.  Opaque attributes are those that are carried in RADIUS, but not parsed or directly acted upon by a RADIUS server.


The revised text that addresses this issue is as follows:


4.  Attributes

  It is important to note that the location specific parts of the
  attributes defined below are not meant to be processed by the RADIUS
  server.  Instead, a location server specific component used in
  combination with the RADIUS server is responsible for receiving,
  processing and further distributing location information (in
  combination with proper access control and privacy protection).  As
  such, from a RADIUS server point of view location information is
  treated as opaque data.


This text does not reference the Design Guidelines, but rather simply declares that the attributes in question are to be considered opaque.  I think this is a bit superficial, but probably suffices to address the issue.

2. A second issue is whether RADIUS servers are expected to be able to parse and act upon these various defined "string" data sets.  In the IETF Last Call discussion, these seemed to be some confusion as to whether this document required RADIUS servers (at least those implementing these
attributes) to be "location aware" i.e. to be able to parse and act
intelligently upon the content of the location information. 

The added text of Section 4 addresses this issue, too.

While I have some lingering concerns that the attribute design style of this document may be viewed as a model for future work, as there is no explicit acknowledgement that it diverges from the Design Guidelines, I think that the added text is sufficient to close the DISCUSS.

[Ballot comment]
I have reviewed the specification and the last call discussion,
and I believe the document is ready to be approved. I think the
authors have struck the right balance between keeping the location
information opaque vs. allowing servers to make authorization
decisions IF they need to do it.

A few minor comments. Section 4.7:

  The numerical value representing FUTURE_REQUESTS indicates that
  the RADIUS client MUST provide future Access-Requests with the
  same information as returned in the initial Access-Request
  message.

To avoid confusion, please change s/future Access-Requests/future
Access-Requests for the same session/

Security Considerations say:

  Confidentiality protection is not only a property
  required by this document, it is also required for the transport
  of keying material in the context of EAP authentication and
  authorization.  Hence, this requirement is, in many environments,
  already fulfilled.

Heh. Or at least the requirement is already present for other reasons
in many environments. Fulfillment is another question...

I'm not asking for any change here.

[Ballot comment]
Section 4.7:

  The numerical value representing FUTURE_REQUESTS indicates that
  the RADIUS client MUST provide future Access-Requests with the
  same information as returned in the initial Access-Request
  message.

To avoid confusion, please change s/future Access-Requests/future
Access-Requests for the same session/

Security Considerations say:

  Confidentiality protection is not only a property
  required by this document, it is also required for the transport
  of keying material in the context of EAP authentication and
  authorization.  Hence, this requirement is, in many environments,
  already fulfilled.

Heh. Or at least the requirement is already present for other reasons
in many environments. Fulfillment is another question...

I'm not asking for any change here.

[Ballot comment]
Section 4.7:

  The numerical value representing FUTURE_REQUESTS indicates that
  the RADIUS client MUST provide future Access-Requests with the
  same information as returned in the initial Access-Request
  message.

To avoid confusion, please change s/future Access-Requests/future
Access-Requests for the same session/

[Ballot discuss]
This is a Discuss Discuss.  I will either move to No Object or revise to make this
actionable after the call.

This specification permits multiple Location-Information and Location-Data attribute pairs.
Are there issues with respect to inconsistency between the civic and geospatial locations?
Are there good reasons to request (or supply) both locations?  I could imagine scenarios
where both locations are known with sighting times, or wildly different granularities and
this could result in conflicting authorization decisions or billing results.  Should the spec
provide any guidance?

[Ballot discuss]
The content for this DISCUSS includes comments from AAA-Doctor David Nelson

The following is based in IETF Last Call comments that seem not to have ben resolved.

This document needs at the very least an IESG Note calling attention to the fact that certain of the RADIUS attributes fail to meet either the letter or spirit of the RADIUS Design Guidelines as to what may properly constitute an "opaque" attribute.  Opaque attributes are those that are carried in RADIUS, but not parsed or directly acted upon by a RADIUS server.

The classic example of an opaque attribute is the EAP-Message Attribute.

This issue was discussed with the authors and in comments upon various early versions of the draft on the RADEXT WG mailing list (some CC'ed to the GEOPRIV WG mailing list).

In fairness, some improvement in attribute design has occurred with successive versions.  Still, there are several attributes that define sub-fields within them, contrary to the guidance of the RADIUS Design Guidelines.

The most recent discussion of these issues occurred during IETF Last Call on the draft. Some of that discussion is captured in the following e-mail messages.

Pointers to some of the IEFT Last call e-mails are as follows:

http://www.ietf.org/mail-archive/web/ietf/current/msg51691.html

http://www.ietf.org/mail-archive/web/ietf/current/msg51686.html

http://www.ietf.org/mail-archive/web/ietf/current/msg51664.html

There are good reasons for the guidelines.  One of the design principles is to allow RADIUS servers to "enroll" new attributes by means of additions of a data dictionary.  This works well for attributes that follow the regular attribute template and standard data types defined in RFC 2865.  The problem comes when the "string" (i.e. undistinguished octets) data type is used to encapsulate a "sub-protocol" i.e. multiple fields that have various forms of delimiters.  While anyone can code an implementation to follow this design technique, it does not lend itself to data-driven design, and is relegated to hand-coded processing.

A second issue is whether RADIUS servers are expected to be able to parse and act upon these various defined "string" data sets.  In the IETF Last Call discussion, these seemed to be some confusion as to whether this document required RADIUS servers (at least those implementing these
attributes) to be "location aware" i.e. to be able to parse and act intelligently upon the content of the location information.

In the example for the EAP-Message Attribute, it is generally understood that the EAP server function is logically distinct from the RADIUS server function, and its functionality is defined in separate RFCs, even if in a particular implementation the code modules are comingled.

Another RADIUS design / documentation principle is that one does not define the functionality of a *service* in a RADIUS document.  The service is defined elsewhere, and the RADIUS document only defines attributes for authorizing or provisioning that service.

If the GEOPRIV Location Information attributes require the complex, structured attribute values, as present in the current draft, then use of RADIUS Extended Attributes, which provide a formalized mechanism for structuring and grouping, is the recommended design practice.

It looks that the least that is required of this document is to point out the inconsistencies with the RADIUS Design Guidelines, and warn readers of the document not to consider it a precedent for new design work, but rather steer them to the RADIUS Design Guidelines document for design guidance.

[Ballot discuss]
(extended content for this DISCUSS includes comments from AAA-Doctor David Nelson)

1. The issue of having the OPS ADs act as contact person for the REALM registry was not discussed with this AD, and seems odd. It is not clear what this implies. It also is not clear why the Expert Reviewer should not be nominated by the IESG, instead of having the OPS AD and RADEXT WG chairs as per section 8.1. Note that the RADEXT WG may shut down at some point in time.

2. The following is based in IETF Last Call comments that seem not to have ben resolved.

This document needs at the very least an IESG Note calling attention to the fact that certain of the RADIUS attributes fail to meet either the letter or spirit of the RADIUS Design Guidelines as to what may properly constitute an "opaque" attribute.  Opaque attributes are those that are carried in RADIUS, but not parsed or directly acted upon by a RADIUS server.

The classic example of an opaque attribute is the EAP-Message Attribute.

This issue was discussed with the authors and in comments upon various early versions of the draft on the RADEXT WG mailing list (some CC'ed to the GEOPRIV WG mailing list).

In fairness, some improvement in attribute design has occurred with successive versions.  Still, there are several attributes that define sub-fields within them, contrary to the guidance of the RADIUS Design Guidelines.

The most recent discussion of these issues occurred during IETF Last Call on the draft. Some of that discussion is captured in the following e-mail messages.

Pointers to some of the IEFT Last call e-mails are as follows:

http://www.ietf.org/mail-archive/web/ietf/current/msg51691.html

http://www.ietf.org/mail-archive/web/ietf/current/msg51686.html

http://www.ietf.org/mail-archive/web/ietf/current/msg51664.html

There are good reasons for the guidelines.  One of the design principles is to allow RADIUS servers to "enroll" new attributes by means of additions of a data dictionary.  This works well for attributes that follow the regular attribute template and standard data types defined in RFC 2865.  The problem comes when the "string" (i.e. undistinguished octets) data type is used to encapsulate a "sub-protocol" i.e. multiple fields that have various forms of delimiters.  While anyone can code an implementation to follow this design technique, it does not lend itself to data-driven design, and is relegated to hand-coded processing.

A second issue is whether RADIUS servers are expected to be able to parse and act upon these various defined "string" data sets.  In the IETF Last Call discussion, these seemed to be some confusion as to whether this document required RADIUS servers (at least those implementing these
attributes) to be "location aware" i.e. to be able to parse and act intelligently upon the content of the location information.

In the example for the EAP-Message Attribute, it is generally understood that the EAP server function is logically distinct from the RADIUS server function, and its functionality is defined in separate RFCs, even if in a particular implementation the code modules are comingled.

Another RADIUS design / documentation principle is that one does not define the functionality of a *service* in a RADIUS document.  The service is defined elsewhere, and the RADIUS document only defines attributes for authorizing or provisioning that service.

If the GEOPRIV Location Information attributes require the complex, structured attribute values, as present in the current draft, then use of RADIUS Extended Attributes, which provide a formalized mechanism for structuring and grouping, is the recommended design practice.

It looks that the least that is required of this document is to point out the inconsistencies with the RADIUS Design Guidelines, and warn readers of the document not to consider it a precedent for new design work, but rather steer them to the RADIUS Design Guidelines document for design guidance.

[Ballot discuss]
(extended content for this DISCUSS includes comments from AAA-Doctor Bernard Aboba)

1. The issue of having the OPS ADs act as contact person for the REALM registry was not discussed with this AD, and seems odd. It is not clear what this implies. It also is not clear why the Expert Reviewer should not be nominated by the IESG, instead of having the OPS AD and RADEXT WG chairs as per section 8.1. Note that the RADEXT WG may shut down at some point in time.

2. The following is based in IETF Last Call comments that seem not to have ben resolved.

This document needs at the very least an IESG Note calling attention to the fact that certain of the RADIUS attributes fail to meet either the letter or spirit of the RADIUS Design Guidelines as to what may properly constitute an "opaque" attribute.  Opaque attributes are those that are carried in RADIUS, but not parsed or directly acted upon by a RADIUS server.

The classic example of an opaque attribute is the EAP-Message Attribute.

This issue was discussed with the authors and in comments upon various early versions of the draft on the RADEXT WG mailing list (some CC'ed to the GEOPRIV WG mailing list).

In fairness, some improvement in attribute design has occurred with successive versions.  Still, there are several attributes that define sub-fields within them, contrary to the guidance of the RADIUS Design Guidelines.

The most recent discussion of these issues occurred during IETF Last Call on the draft. Some of that discussion is captured in the following e-mail messages.

Pointers to some of the IEFT Last call e-mails are as follows:

http://www.ietf.org/mail-archive/web/ietf/current/msg51691.html

http://www.ietf.org/mail-archive/web/ietf/current/msg51686.html

http://www.ietf.org/mail-archive/web/ietf/current/msg51664.html

There are good reasons for the guidelines.  One of the design principles is to allow RADIUS servers to "enroll" new attributes by means of additions of a data dictionary.  This works well for attributes that follow the regular attribute template and standard data types defined in RFC 2865.  The problem comes when the "string" (i.e. undistinguished octets) data type is used to encapsulate a "sub-protocol" i.e. multiple fields that have various forms of delimiters.  While anyone can code an implementation to follow this design technique, it does not lend itself to data-driven design, and is relegated to hand-coded processing.

A second issue is whether RADIUS servers are expected to be able to parse and act upon these various defined "string" data sets.  In the IETF Last Call discussion, these seemed to be some confusion as to whether this document required RADIUS servers (at least those implementing these
attributes) to be "location aware" i.e. to be able to parse and act intelligently upon the content of the location information.

In the example for the EAP-Message Attribute, it is generally understood that the EAP server function is logically distinct from the RADIUS server function, and its functionality is defined in separate RFCs, even if in a particular implementation the code modules are comingled.

Another RADIUS design / documentation principle is that one does not define the functionality of a *service* in a RADIUS document.  The service is defined elsewhere, and the RADIUS document only defines attributes for authorizing or provisioning that service.

If the GEOPRIV Location Information attributes require the complex, structured attribute values, as present in the current draft, then use of RADIUS Extended Attributes, which provide a formalized mechanism for structuring and grouping, is the recommended design practice.

It looks that the least that is required of this document is to point out the inconsistencies with the RADIUS Design Guidelines, and warn readers of the document not to consider it a precedent for new design work, but rather steer them to the RADIUS Design Guidelines document for design guidance.

[Ballot discuss]
1. The issue of having the OPS ADs act as contact person for the REALM registry was not discussed with this AD, and seems odd. It is not clear what this implies. It also is not clear why the Expert Reviewer should not be nominated by the IESG, instead of having the OPS AD and RADEXT WG chairs as per section 8.1. Note that the RADEXT WG may shut down at some point in time.

2. The following is based in IETF Last Call comments that seem not to have ben resolved and follow-up dicussions on the AAA-Doctors list.

This document needs at the very least an IESG Note calling attention to the fact that certain of the RADIUS attributes fail to meet either the letter or spirit of the RADIUS Design Guidelines as to what may properly constitute an "opaque" attribute.  Opaque attributes are those that are carried in RADIUS, but not parsed or directly acted upon by a RADIUS server.

The classic example of an opaque attribute is the EAP-Message Attribute.

This issue was discussed with the authors and in comments upon various early versions of the draft on the RADEXT WG mailing list (some CC'ed to the GEOPRIV WG mailing list).

In fairness, some improvement in attribute design has occurred with successive versions.  Still, there are several attributes that define sub-fields within them, contrary to the guidance of the RADIUS Design Guidelines.

The most recent discussion of these issues occurred during IETF Last Call on the draft. Some of that discussion is captured in the following e-mail messages.

Pointers to some of the IEFT Last call e-mails are as follows:

http://www.ietf.org/mail-archive/web/ietf/current/msg51691.html

http://www.ietf.org/mail-archive/web/ietf/current/msg51686.html

http://www.ietf.org/mail-archive/web/ietf/current/msg51664.html

There are good reasons for the guidelines.  One of the design principles is to allow RADIUS servers to "enroll" new attributes by means of additions of a data dictionary.  This works well for attributes that follow the regular attribute template and standard data types defined in RFC 2865.  The problem comes when the "string" (i.e. undistinguished octets) data type is used to encapsulate a "sub-protocol" i.e. multiple fields that have various forms of delimiters.  While anyone can code an implementation to follow this design technique, it does not lend itself to data-driven design, and is relegated to hand-coded processing.

A second issue is whether RADIUS servers are expected to be able to parse and act upon these various defined "string" data sets.  In the IETF Last Call discussion, these seemed to be some confusion as to whether this document required RADIUS servers (at least those implementing these
attributes) to be "location aware" i.e. to be able to parse and act intelligently upon the content of the location information.

In the example for the EAP-Message Attribute, it is generally understood that the EAP server function is logically distinct from the RADIUS server function, and its functionality is defined in separate RFCs, even if in a particular implementation the code modules are comingled.

Another RADIUS design / documentation principle is that one does not define the functionality of a *service* in a RADIUS document.  The service is defined elsewhere, and the RADIUS document only defines attributes for authorizing or provisioning that service.

If the GEOPRIV Location Information attributes require the complex, structured attribute values, as present in the current draft, then use of RADIUS Extended Attributes, which provide a formalized mechanism for structuring and grouping, is the recommended design practice.

It looks that the least that is required of this document is to point out the inconsistencies with the RADIUS Design Guidelines, and warn readers of the document not to consider it a precedent for new design work, but rather steer them to the RADIUS Design Guidelines document for design guidance.

[Ballot discuss]
The issue of having the OPS ADs act as contact person for the REALM registry was not discussed with this AD, and seems odd. It is not clear what this implies. It also is not clear why the Expert Reviewer should not be nominated by the IESG, instead of having the OPS AD and RADEXT WG chairs as per section 8.1. Note that the RADEXT WG may shut down at some point in time.

[Ballot discuss]
There was a dialogue between Glen Zorn and Bernard Aboba during IETF
  Last Call.  I expected the dialogue to result in chanes to the
  document since the last message included:
  >
  > Given that two readers have come to such widely differing
  > interpretations of the same text, I'd suggest that these
  > ambiguities need to be cleared up.
  >
  Yet, the document has not been updated and there are not notes to
  the RFC Editor to resolve this issue.

[Ballot comment]
Section 4.1., paragraph 17:
>        Example: anyisp.example.com

  Suggest to move this example down to the description of the REALM
  namespace, because it's specific to it. (It confused me on first
  reading to see the example and then read about namespaces where it
  isn't valis.) It might also be good to add one example to each of the
  other namespaces.


Section 4.2., paragraph 2:
>    The Location-Information Attribute provides meta-data about the
>    location information, such as sighting time, time-to-live, location
>    determination method, etc.  Implementations SHOULD treat this
>    attribute as undistinguished octets, like the Location-Data Attribute
>    to which it refers.

  Why is this a SHOULD and not a MUST? Under what conditions may
  implementations interpret the attribute? (The same comment applies to
  other attributes below.)


Section 4.4., paragraph 19:
>      Note Well (variable):
>        This field contains a URI that points to human readable
>        privacy instructions. The data type of this field is string.

  The APP ADs should look at this. I'm not an i18n expert, but it seems
  pretty important to transport a URI here that points to something a
  user can understand.


Section 4.4., paragraph 21:
>    retransmission-allowed:
>      When the value of this field is to zero (0), then the recipient of
>      this Location Object is not permitted to share the enclosed
>      location information, or the object as a whole, with other
>      parties.

  Are there any protocol or encoding mechanisms in place to prevent this
  sharing, or do we simply trust the other end to conform to our wishes?
  (Same issue applies to "retention-expires".)


Section 4.6., paragraph 1:
>    A RADIUS server SHOULD NOT
>    challenge for location information unless the Location-Capable
>    Attribute has been sent to it.

  Why is this a SHOULD NOT? When is it permissible to challenge?


Section 6., paragraph 2:
>                                      |    |    |SHLD| MUST|    |

  s/SHLD/SHOULD/ (don't abbreviate RFC2119 terms)


Section 8.1., paragraph 3:
>  |  0x31  | REALM              | IETF O&M Area Directors            |
>  |          |                    | (ops-chairs@ietf.org)              |

  The ADs are at ops-ads@ietf.org.


Section 8.2., paragraph 6:
>    No mechanism to mark entries as "deprecated" is
>    envisioned.  Based on expert approval it is possible to delete
>    entries from the registry.

  It's usually much safer to deprecate registry entries or to make them
  historic, compared to simply removing them. Is there a particular
  reason for this choice? (Same comment applies to other registries.)


Section 9., paragraph 1:
>    We would like to thank Bernhard Aboba for the numerous contributions
>    to this document.

  It's a bit unusual to thank a co-author, but hey :-)

[Ballot discuss]
Section 4.7., paragraph 8:
>    If the RADIUS server does not send a Requested-Location-Info
>    Attribute then the RADIUS client MUST NOT attach location information
>    to messages towards the RADIUS server, unless an out-of-band
>    agreement is in place.

  Discuss-discuss: I may be missing something here, but why is it useful
  to allow an out-of-band agreement to override protocol semantics? If
  there's an agreement that this information is to always be exchanged,
  the server should simply always send Requested-Location-Info and then
  the client should include it.


Section 8.1., paragraph 6:
>    Requests to IANA for a new value for a Namespace ID will be approved
>    by Expert Review.  The Designated Expert Reviewer team for these
>    requests is the current Operations Area Director and the RADEXT
>    working group chairs or the working group chairs of a designated
>    successor working group.

  Discuss: It is up to the IESG to appoint designated experts, not a
  published RFC. (The appointment may change over time.) The same issue
  exists for other registries, and some have a related issue where it's
  claimed that the OPS ADs appoint experts.


Section 11.2., paragraph 5:
>    [I-D.ietf-radext-rfc3576bis]
>              Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
>              Aboba, "Dynamic Authorization Extensions to Remote
>              Authentication Dial In User  Service (RADIUS)",
>              draft-ietf-radext-rfc3576bis-13 (work in progress),
>              October 2007.

  Discuss: The way this (now published as RFC5176) is used in Section
  3.3 and Section 8 makes me think this needs to be a normative
  reference. But it's an Informational RFC, which would make this a
  DOWNREF.

IANA review comments:

Action #1:

Upon approval of this document, the IANA will make the following
Assignments in the "Radius Types" registry at
http://www.iana.org/assignments/radius-types
sub-registry "Radius Attribute Types"

Value Description Reference
----- ----------- ---------
TBD1 Operator-Name [RFC-geopriv-radius-lo-19]
TBD2 Location-Information [RFC-geopriv-radius-lo-19]
TBD3 Basic-Policy-Rules [RFC-geopriv-radius-lo-19]
TBD4 Extended-Policy-Rules [RFC-geopriv-radius-lo-19]
TBD5 Challenge-Capable [RFC-geopriv-radius-lo-19]
TBD6 Requested-Info [RFC-geopriv-radius-lo-19]


Action #2:

Upon approval of this document, the IANA will make the following
assignments in the "Radius Types" registry at
http://www.iana.org/assignments/radius-types
sub-registry "Values for RADIUS Attribute 101, Error-Cause Attribute"

Value Description Reference
----- ----------- ---------
TBD5xx Location Information Required [RFC-geopriv-radius-lo-19]


Action #3:

Upon approval of this document, the IANA will create the following 
registry at http://www.iana.org/assignments/radius-types

Registry Name: Operator Namespace Identifier
Registration Procedures: Expert Review

Registry:
|Identifier| Operator Namespace Token | Contact Person |Reference
| 0x30 | TADIG | TD.13 Coordinator (td13@gsm.org) |[RFC-geopriv-radius-lo-19]
| 0x31 | REALM | IETF O&M Area Directors (ops-chairs@ietf.org) |[RFC-geopriv-radius-lo-19]
| 0x32 | E212 | ITU Director (tsbdir@itu.int) |[RFC-geopriv-radius-lo-19]
| 0x33 | ICC | ITU Director (tsbdir@itu.int) |[RFC-geopriv-radius-lo-19]


Action #4:

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/radius-types

Registry Name: Location Capable Attribute
Registration Procedures: Expert Review

Registry:
Bit | Semanitc | Reference
-------+---------------------+---------
0-30 | Unassigned
31 | Location Capable | [RFC-geopriv-radius-lo-19]


Action #5:

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/radius-types

Registry Name: Entity Types
Registration Procedures: Expert Review

Registry:
Value | Description | Reference
-------+---------------------+---------
0 |User client Location | [RFC-geopriv-radius-lo-19]
1 | Radius Client Locatione | [RFC-geopriv-radius-lo-19]
2-255 | Unassigned


Action #6:

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/radius-types

Registry Name: Privacy Flags
Registration Procedure: Expert Review

Registry:
Bit | Description | Reference
-------+---------------------+---------
0 |Retransmission allowed | [RFC-geopriv-radius-lo-19]
1-15 | Unassigned


Action #7:

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/radius-types

Registry Names: Requested-Info Attribute
Registration Procedures: Expert Review

Registry:
| Value | Capability Token | Reference |
-------------------------------
| 0-27 | Unassigned
| 28 | NAS_LOCATION | [RFC-geopriv-radius-lo-19] |
| 29 | USERS_LOCATION | [RFC-geopriv-radius-lo-19] |
| 30 | GEO_LOCATION | [RFC-geopriv-radius-lo-19] |
| 31 | CIVIC_LOCATION | [RFC-geopriv-radius-lo-19] |

We understand the above to be the only IANA Actions for this
document.

The GEOPRIV working group requests publication of draft-ietf-geopriv-
radius-lo-19.txt as a Proposed Standard.

----

Technical Summary

This document specifies RADIUS attributes for conveying access
network location information, in both civic and geospatial location
formats, along with access network ownership.  The distribution of
location information is a privacy sensitive task.  Dealing with
mechanisms to preserve the user's privacy is important and is
addressed throughout, for various scenarios of location information
function within AAA.

WG Summary

The WG reached solid consensus to advance this document after
a number of iterations.  The WG had initial hesitation about
taking on the work, because the RFC 4119 pidf_lo object could
not be used within RADIUS attribute size constraints.  The
WG concerns were met with an eventual functional compromise,
providing a mandated attribute with the pidf_lo policy markers,
and opaque attributes pointing to the geopriv location
formats developed for DHCP which had constraints similar
to RADIUS.

This document is a Critical Requirement for 3GPP.  Both the
GSM Association and the ITU have specified Operator Namespace
Tokens for use in this protocol.  (The document has customers).


Document Quality

The protocol was reviewed in depth by both the GEOPRIV and
RADEXT Working Groups.  RADEXT's formal issues list was
cleared.  GEOPRIV and RADEXT had some overlapping
issues, especially location information design,
and scenario evaluation.  The conclusion that location-
aware AAA systems need to be able to implement the
formats and processing found in the GEOPRIV documents
was very useful, because it meant that GEOPRIV did not
have to intercept or anticipate any enhancements of the
RADIUS data model.

The document is especially careful in projecting GEOPRIV's
paranoia towards exposing location information.  Section
8.3 contains a detailed review against the previously
defined requirements related to this, and the Security
Considerations details the use of security services
RADIUS provides as the using protocol to meet requirements.

An earlier version of this draft (-10) went through IETF LC. The
need for substantive changes were identified and have been made.
These changes have been reviewed by the GEOPRIV and DIME
working groups.

Personnel

The WG Chair shepherd is Robert Sparks and the Responsible
Area Director is Cullen Jennings.

The IESG announces that the current Operations Area Director,
along with the current RADEXT WG Chairs, are the designated Expert
Reviewers for Operator Namespace Tokens,  as specified in
Section 8.1.

[IANA registers these as role email addresses,
radext-chairs@tools.ietf.org, oam-ads@tools.ietf.org]

------- The proto writeup follows. This has been adapted from the 
--------
------- geopriv chair's writeup of 
-10                                                      --------


  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The shepherd is Robert Sparks.  I have personally reviewed it and
believe it is ready for forwarding.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

It has been reviewed carefully by key WG members, by key RADEXT WG
members, and by both WGs. The diameter specific content was reviewed 
by DIME.
I do not have concerns.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

The group sought specific review on these prior to publication 
request for -10:
AAA, operations usability and scenarios, security and privacy, 
location applicability, other SDO
relatability, and internationalization.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the 
document, or
          has concerns whether there really is a need for it.  In any
          event, if those issues have been discussed in the WG and the
          WG has indicated that it still wishes to advance the 
document,
          detail those concerns here.

The IANA considerations section reflects an IESG opinion that might 
be stale.
It warrants a careful read and early feedback from IANA.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is solid WG consensus.  There was a lengthy process to gain
RADEXT WG consensus with the design, but we succeeded once the location
information was presented as opaque material specified in GEOPRIV
standards. (Only a small core of the GEOPRIV working group engaged in 
the
  -10 to -19 discussions, but there was adequate review and the 
changes were
well vetted with the group,)

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. 
(It
          should be in a separate email because this questionnaire will
          be entered into the ID Tracker.)

Nothing.

  (1.g)  Has the Document Shepherd verified that the document satisfies
          all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.

The document has passed this checklist.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents 
that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative 
references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references are split.


  (1.i) Has the Document Shepherd verified that the document IANA 
consideration
  section exists and is consistent with the body of the document? If 
the document
  specifies protocol extensions, are reservations requested in 
appropriate IANA
  registries? Are the IANA registries clearly identified? If the 
document creates a
  new registry, does it define the proposed initial contents of the 
registry and an
  allocation procedure for future registrations? Does it suggest a 
reasonable
    name for the new registry? See [RFC2434]. If the document 
describes an
  Expert Review process has Shepherd conferred with the Responsible 
Area
  Director so that the IESG can appoint the needed Expert during the 
IESG
  Evaluation?

The document has an extensive IANA considerations section that 
creates 6 new registries
across RADIUS and DIAMETER, all using expert review directed by the 
O&M ADs and RADEXT chairs.
The registries are well defined and named. If there's a problem w/ 
the clarity of IANA instructions
here its in determining which registry lands in which namespace.

  (1.j) Has the Document Shepherd verified that sections of the 
document that are
    written in a formal language, such as XML code, BNF rules, MIB 
definitions, etc.,
    validate correctly in an automated checker?

There is no such formal language used in this document. There are 
network byte diagrams and those
have been manually reviewed.


  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.

See first of message

I think some really serious issues came up on this document in IETF LC around the usage of Radius. I would like to take this back to the geopriv WG and make sure we can resolve these in a way that works for the Radius folks.

State Change Notice email list have been change to geopriv-chairs@tools.ietf.org, avi@bridgewatersystems.com, mark.jones@bridgewatersystems.com, farid.adrangi@intel.com, Hannes.Tschofenig@siemens.com from geopriv-chairs@tools.ietf.org,  mankin@psg.com, avi@bridgewatersystems.com, mark.jones@bridgewatersystems.com, farid.adrangi@intel.com, Hannes.Tschofenig@siemens.com,

I am working on getting some help to resolve the LC comments from Radius folks. I suspect that we will need a new version of the document.

IANA Last Call Comments:


Action #1: (from 5.1- 5.x)

"RADIUS Attribute Types"
http://www.iana.org/assignments/radius-types
TDB1 Operator-Name [RFC-geopriv-radius-lo-10]
TDB2 Location-Information [RFC-geopriv-radius-lo-10]
TDB3 Location-Info-Civic [RFC-geopriv-radius-lo-10]
TDB4 Location-Info-Geo [RFC-geopriv-radius-lo-10]
TDB5 Basic-Policy-Rules [RFC-geopriv-radius-lo-10]
TDB6 Extended Policy Rules [RFC-geopriv-radius-lo-10]
TDB7 Challenge-Capable [RFC-geopriv-radius-lo-10]
TDB8 Requested-Info [RFC-geopriv-radius-lo-10]

Action #2 (5.1)
Create sub-registry for TDB1 in
"Values for Attribute TDB1 Operator Name
[RFC-geopriv-radius-lo-10]

http://www.iana.org/assignments/radius-types

+----------+--------------------+------------------------------------+
|Identifier| Operator Namespace | Contact Person | REF
| | Token | |
+----------+--------------------+------------------------------------+
| 0 | TADIG | Christer Gullstrand | [RFC-
geopriv-radius-lo-10]
| | | (Christer.Gullstrand@syniverse.com)|
| 1 | REALM | Hannes Tschofenig | [RFC-
geopriv-radius-lo-10]
| | | (Hannes.Tschofenig@siemens.com) |
| 2 | E212 | ITU Director | [RFC-
geopriv-radius-lo-10]
| | | (tsbdir@itu.int) |
| 3 | ICC | ITU Director | [RFC-
geopriv-radius-lo-10]
| | | (tsbdir@itu.int) |
+----------+--------------------+------------------------------------+


Allocation-policy: Expert review Section 11.1
-- rules
Requests to IANA for a new value for a Namespace ID
will be approved by Expert Review. The Designated Expert
Reviewer team for these requests is the current Operations
Area Director and the RADEXT working group chairs or the
working group chairs of a designated successor working
group.

The Expert Reviewer should ensure that a new entry is
indeed required or could fit within an existing database,
e.g., whether there is a real requirement to provide a
token for an Namespace ID because one is already up and
running, or whether the REALM identifier plus the
name should recommended to the requester. In addition,
the Expert Reviewer should ascertain to some reasonable
degree of diligence that a new entry is a correct reference
to an Operator Namespace, when a new one is registered.

--- end rules


Action #3 (5.5)
Create sub-registry for TDB5
"Values for Attribute TDB5 Basic Policy Rules"
[RFC-geopriv-radius-lo-10]

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|o o o o o o o o o o o o o o o|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flags defined
bit 0 R - retransmission allowed
bit 1-15 reserved

Allocation policy ????

Action #4 (5.8)
Create sub-registry for TDB8 in
"Values for Attribute TDB8 Requested-Info Attribute [RFC-geopriv-radius-lo-10]"
http://www.iana.org/assignments/radius-types

0 Reserved
1 CIVIC_LOCATION [RFC-geopriv-radius-lo-10]
2 GEO_LOCATION [RFC-geopriv-radius-lo-10]
4 USERS_LOCAION [RFC-geopriv-radius-lo-10]
8 NAS_LOCATION [RFC-geopriv-radius-lo-10]
2^x available for assignement [RFC-geopriv-radius-lo-10]

Allocation rule only numberic values that are 2^x are
allowed Allocation Policy:

Following the policies outline in [8] new Capability Tokens
with a description of their semantic for usage with the
Requested-Info attribute will be assigned after Expert
Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group
chairs of a designated successor working group.

Updates can be provided based on expert approval only. A
designated expert will be appointed by the O&M Area
Directors. No mechanism to mark entries as "deprecated"
is envisioned. Based on expert approval it is possible to
delete entries from the registry.

Each registration must include:

Name:

Capability Token (i.e., an identifier of the capability)


Description:

Brief description indicating the meaning of the info element.


Numerical Value:

A numerical value that is placed into the Capability
attribute representing a bit in the bit-string of the
Requested-Info attribute.


We understand the above to be the only IANA Action for
this document.

Document Shepherd Write-Up

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The shepherd is Allison Mankin.  I have personally reviewed it and
believe it is ready for forwarding.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

It has been reviewed carefully by key WG members, by key RADEXT WG
members, and by both WGs.  I do not have concerns.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

We have sought specific review on these: AAA, operations usability and
scenarios, security and privacy, location applicability, other SDO
relatability, and internationalization.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if those issues have been discussed in the WG and the
          WG has indicated that it still wishes to advance the document,
          detail those concerns here.

No concerns.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is solid WG consensus.  There was a lengthy process to gain
RADEXT WG consensus with the design, but we succeeded once the location
information was presented as opaque material specified in GEOPRIV
standards.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire will
          be entered into the ID Tracker.)

Nothing.

  (1.g)  Has the Document Shepherd verified that the document satisfies
          all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.

The document has passed this checklist.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references are split. 

There is one normative downward reference -
  RFC 3576 - Informational
  Dynamic Authorization Extensions to Remote Authentication
  Dial In User Service,
  Because RFC 3576 is widely implemented, the draft defines
  handling for 3567 dynamic authorizations normatively
  Therefore we think RFC 3567 needs to have the RFC 3967/BCP 97
  downref procedure.

  (1.i)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

State Change Notice email list have been change to geopriv-chairs@tools.ietf.org,  mankin@psg.com, avi@bridgewatersystems.com, mark.jones@bridgewatersystems.com, farid.adrangi@intel.com, Hannes.Tschofenig@siemens.com, from geopriv-chairs@tools.ietf.org,  amankin@nsf.gov, avi@bridgewatersystems.com, mark.jones@bridgewatersystems.com, farid.adrangi@intel.com, Hannes.Tschofenig@siemens.com,

The WG Last Call on Carrying Location Objects in RADIUS ended quietly.
Hannes addressed the last issues that came from us between revs 9 and
10.  There were no comments from RADEXT on the WGLC message forwarded
to them by me and also by Bernard, and we took more than two months
to mull (the shepherd got an office job - amankin@nsf.gov if we have
non-IETF things to talk about :)

So we hereby submit this draft for publication.  Here's my PROTO diligence -

Document Shepherd Write-Up

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The shepherd is Allison Mankin.  I have personally reviewed it and
believe it is ready for forwarding.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

It has been reviewed carefully by key WG members, by key RADEXT WG
members, and by both WGs.  I do not have concerns.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

We have sought specific review on these: AAA, operations usability and
scenarios, security and privacy, location applicability, other SDO
relatability, and internationalization.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if those issues have been discussed in the WG and the
          WG has indicated that it still wishes to advance the document,
          detail those concerns here.

No concerns.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is solid WG consensus.  There was a lengthy process to gain
RADEXT WG consensus with the design, but we succeeded once the location
information was presented as opaque material specified in GEOPRIV
standards.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire will
          be entered into the ID Tracker.)

Nothing.

  (1.g)  Has the Document Shepherd verified that the document satisfies
          all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.

The document has passed this checklist.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references are split. 

There is one normative downward reference -
  RFC 3576 - Informational
  Dynamic Authorization Extensions to Remote Authentication
  Dial In User Service,
  Because RFC 3576 is widely implemented, the draft defines
  handling for 3567 dynamic authorizations normatively
  Therefore we think RFC 3567 needs to have the RFC 3967/BCP 97
  downref procedure.

  (1.i)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

Technical Summary

This document specifies RADIUS attributes for conveying access
network location information, in both civic and geospatial location
formats, along with access network ownership.  The distribution of
location information is a privacy sensitive task.  Dealing with
mechanisms to preserve the user's privacy is important and is
addressed throughout, for various scenarios of location information
function within AAA.

WG Summary

The WG reached solid consensus to advance this document after
a number of iterations.  The WG had initial hesitation about
taking on the work, because the RFC 4119 pidf_lo object could
not be used within RADIUS attribute size constraints.  The
WG concerns were met with an eventual functional compromise,
providing a mandated attribute with the pidf_lo policy markers,
and opaque attributes pointing to the geopriv location
formats developed for DHCP which had constraints similar
to RADIUS. 

This document is a Critical Requirement for 3GPP.  Both the
GSM Association and the ITU have specified Operator Namespace
Tokens for use in this protocol.  (The document has customers).

Document Quality

The protocol was reviewed in depth by both the GEOPRIV and
RADEXT Working Groups.  RADEXT's formal issues list was
cleared.  GEOPRIV and RADEXT had some overlapping
issues, especially location information design,
and scenario evaluation.  The conclusion that location-
aware AAA systems need to be able to implement the
formats and processing found in the GEOPRIV documents
was very useful, because it meant that GEOPRIV did not
have to intercept or anticipate any enhancements of the
RADIUS data model.

The document is especially careful in projecting GEOPRIV's
paranoia towards exposing location information.  Section
8.3 contains a detailed review against the previously
defined requirements related to this, and the Security
Considerations details the use of security services
RADIUS provides as the using protocol to meet requirements.

Personnel

The WG Chair shepherd is Allison Mankin and the Responsible
Area Director is Cullen Jennings.

The IESG announces that the current Operations Area Director,
along with the current RADEXT WG Chairs, are the designated Expert
Reviewers for Operator Namespace Tokens,  as specified in
Section 11.1. 

[IANA registers these as role email addresses,
radext-chairs@tools.ietf.org, oam-ads@tools.ietf.org, IMO]