Subject: [Ecrit] FW: Publish Request - draft-ietf-ecrit-location-hiding-req-01

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 10 Nov 2008 10:45:00 +0200

FYI, 

Marc submitted the publication request for
draft-ietf-ecrit-location-hiding-req-01.

Ciao
Hannes

________________________________

	From: Marc Linsner [mailto:[email-masked]] 
	Sent: 07 November, 2008 16:24
	To: [email-masked]; [email-masked]
	Cc: Hannes Tschofenig
	Subject: Publish Request - draft-ietf-ecrit-location-hiding-req-01

	I am requesting to publish draft-ietf-ecrit-location-hiding-req-01
	
	PROTO WRITEUP for draft-ietf-ecrit-location-hiding-req-01.txt
	=============================================================

	   (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?

	      Document Shepherd is Marc Linsner ([email-masked]).
	      The document is ready for publications and I have reviewed the

	      document personally.

	   (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?

	      The document received a lot of reviews within the group. 
	      It was created after long and controversial discussions around

	      feedback obtained from network operators about deploying the 
	      IETF emergency services architecture. 
	
	      There are no concerns about the depth and the breadth of the
reviews. 
	
	   (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?
	          
	      There are no concerns with the document. 

	   (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 the WG has discussed those issues and has
indicated
	          that it still wishes to advance the document, detail those
	          concerns here.  Has an IPR disclosure related to this
document
	          been filed?  If so, please include a reference to the
	          disclosure and summarize the WG discussion and conclusion
on
	          this issue.
	
	      There are 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 consensus behind this document.
	      
	   (1.f)  Has anyone threatened an appeal or otherwise indicated
extreme
	          discontent?  If so, please summarize the areas of conflict
in
	          separate email messages to the Responsible Area Director.
(It
	          should be in a separate email because this questionnaire
is
	          entered into the ID Tracker.)
	          
	      The topic of location hiding was controversal and kept  
	      ECRIT and GEOPRIV participants busy for a while. Key working 
	      group members have expressed a lot of concerns but seem to be 
	      fine with the resulting requirements document. 

	   (1.g)  Has the Document Shepherd personally 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.  Has the
document
	          met all formal review criteria it needs to, such as the
MIB
	          Doctor, media type, and URI type reviews?  If the document
	          does not already indicate its intended status at the top
of
	          the first page, please indicate the intended status here.
	
	      The document does not contain nits. 

	   (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 document has references split into normative and 
	     informative references. 
	     
	   (1.i)  Has the Document Shepherd verified that the document's
IANA
	          Considerations 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 the
Document
	          Shepherd conferred with the Responsible Area Director so
that
	          the IESG can appoint the needed Expert during IESG
Evaluation?
	
	   An IANA consideration section exists but there are not actions
for 
	   IANA since this is a requirements document. 

	   (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?
	
	   The document does not contain formal languages. 

	   (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. 

	Document Announcement Write-Up for "Location Hiding: Problem
Statement 
	and Requirements" (draft-ietf-ecrit-location-hiding-req-01.txt)
	
	   Technical Summary
	
	   The emergency services architecture developed in the IETF
Emergency
	   Context Resolution with Internet Technology (ECRIT) working group
	   describes an architecture where location information is provided
by
	   access networks to end points or VoIP service providers in order
to
	   determine the correct dial string and information to route the
call
	   to a Public Safety Answering Point (PSAP).  For determining the
PSAP
	   Uniform Resource Identifier (URI) the usage of the Location-to-
	   Service Translation (LoST) Protocol is envisioned.
	   
	   This document provides a problem statement and lists requirements
	   for situations where the Internet Access Provider (IAP) and/or
the 
	   Internet Service Provider (ISP) are only willing to disclose 
	   limited or no location information.
	
	   Working Group Summary
	
	      There is consensus in the WG to publish this document.
	
	   Document Quality
	
	      The document has been reviewed by ECRIT working group members
	      and feedback was provided by participants from various 
	      emergency services workshops.
	      
	   Personnel
	
	     Marc Linsner is the document shepherd for this document.   

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit