Subject: [Geopriv] Request publication for draft-ietf-geopriv-radius-lo

From: Allison Mankin <[email-masked]>
Date: Wed, 18 Oct 2006 12:42:43 -0700

[IESG Secretary is bcc'd]

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 - [email-masked] 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,
[email-masked], [email-masked], IMO]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 31 Oct 2006 14:58:25 -0800

I'm not sure why this did not show up in pub requested but I just put  
it there....