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

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

On Oct 18, 2006, at 12:42 PM, Allison Mankin wrote:

> [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 - 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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 31 Oct 2006 14:58:25 -0800