Skip to main content

Trustworthy Location
draft-ietf-ecrit-trustworthy-location-14

Revision differences

Document history

Date Rev. By Action
2014-12-12
14 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-09-26
14 Alissa Cooper Changed consensus to Yes from Unknown
2014-09-24
14 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-09-23
14 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2014-09-05
14 (System) RFC Editor state changed to AUTH from EDIT
2014-08-20
14 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-08-20
14 (System) RFC Editor state changed to EDIT
2014-08-20
14 (System) Announcement was received by RFC Editor
2014-08-19
14 (System) IANA Action state changed to No IC from In Progress
2014-08-19
14 (System) IANA Action state changed to In Progress
2014-08-18
14 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2014-08-18
14 Cindy Morgan IESG has approved the document
2014-08-18
14 Cindy Morgan Closed "Approve" ballot
2014-08-18
14 Cindy Morgan Ballot approval text was generated
2014-08-18
14 Cindy Morgan Ballot writeup was changed
2014-08-15
14 Alissa Cooper Ballot approval text was changed
2014-07-28
14 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-14.txt
2014-07-12
13 Stephen Farrell
[Ballot comment]
- Thanks for adding text in 1.2.1 which is sufficient to
handle the discuss. However, I think you're maybe missing the
punch line …
[Ballot comment]
- Thanks for adding text in 1.2.1 which is sufficient to
handle the discuss. However, I think you're maybe missing the
punch line at the end of 1.2.1 so I'd suggest maybe something
like "Given the above, SIP UAs in practice provide no privacy
for location information whenever the UA is able to determine
location. This will likely lead to some proportion of users
taking whatever steps are possible to prevent location
information being available to the UAC.  In the end, the
consequence of not honoring the user's wishes within the
network, will be that location will not be available (or will
be spoofed) for some emergency calls." But, I doubt you'd want
to go that far, so I won't insist:-)

(As an aside, I'd be interested in thinking about whether or
not we think the whole geopriv effort has been a success in
privacy terms. I've no idea if there'd be energy for that,
but it might be a useful bit of navel gazing for the IETF to
do.)

The comment below is from March. It remains valid I
believe. I don't recall any response to it.

- The title is misleading. I expected to be told how to
do something or how someone had done something but
instead the draft actually discusses pros and cons of
many ways of providing location information for emergency
calls. And no firm conclusion is reached. So I suggest a
tile such as "Issues with Trusting Location" would be a
more appropriate title.
2014-07-12
13 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2014-06-28
13 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-13.txt
2014-06-02
12 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-12.txt
2014-06-01
11 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-11.txt
2014-05-31
10 Bernard Aboba IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-05-31
10 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-10.txt
2014-03-28
09 Meral Shirazipour Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2014-03-27
09 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2014-03-27
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-03-27
09 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2014-03-27
09 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-03-26
09 Pete Resnick
[Ballot comment]
1:

I think the word "prank" is incorrect here. A prank is normally done as a joke or to be mildly mischievous or …
[Ballot comment]
1:

I think the word "prank" is incorrect here. A prank is normally done as a joke or to be mildly mischievous or a nuisance. (See the wikipedia entry for "Prank Call".) Instead, "hoax call" is probably the better term, and the one that is used in the EENA document.

I think the reference to "swatting" makes the intro read as hype rather than a serious piece of technical work. It's not referred to elsewhere in the document. It's fine to refer to the EENA document, and mention the types of attacks, but remove the reference "swatting", and the FBI. They're not appropriate for this document. Leave it to the press releases.

  Ideally, a call taker at a PSAP should be put in the position to
  assess, in real-time, the level of trust that can be placed on the
  information provided within a call.
 
Do you mean that the "call taker at a PSAP should *not* be put in the position to..."? (That is, this shouldn't be the responsibility of a human.) Or do you rather mean that the "call taker at a PSAP should be able to..."? Something's weird in the sentence as written.

2.1: Points 2 and 3 aren't end host attacks.

I have a question about Location swapping: So Trudy gets Malory's location information. Then Malory can contact Trudy's PSAP and report an emergency at Trudy's location. But in this case, when the emergency turns out to be false, Trudy gets blamed *and that's right*, because Trudy colluded. Is the concern simply that somehow Malory won't get any of the blame for participating? What's the spoof here?

2.2: I don't understand how bot-net attacks are relevant here. The lack of doing strong authentication makes the system vulnerable to false identity attacks by the end host, but that's not a bot-net attack. If a bot-net attack is relevant here, you had best explain it.

3.1: I presume the bot-net attack described here (still not defined) is that the bots would be used for a DoS of the PSAP itself. But the damage is done with or without location information, isn't it? Or it could be that you're referring to bots set up to make a particular PSAP think that there was a set of calls from the same location (even though no human was on the other end of the line) and therefore increase the likelihood of an actual emergency. But you don't explain how that attack works. Either way, I'm not clear on what you're talking about here.

Henning thanking himself in the acknowledgements is...creepy.

Stephen and Adrian's comments are well-said. Saved me writing more.
2014-03-26
09 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-03-26
09 Kathleen Moriarty [Ballot comment]
I support Stephen's position
2014-03-26
09 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-03-26
09 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2014-03-26
09 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-03-25
09 Stephen Farrell
[Ballot discuss]

I hope this should be easily resolved.

The draft naturally focuses on the needs and requirements
of emergency services. However, many of the …
[Ballot discuss]

I hope this should be easily resolved.

The draft naturally focuses on the needs and requirements
of emergency services. However, many of the solutions
that might meet those requirements have potentially
serious privacy downsides if those solutions affect many
or most other calls.  That really needs to be noted, with
an example or two. I'd suggest adding a paragraph to both
the intro and the security considertaions sections.
(Think of the latter as being a new risk introducted by
preventing/mitigating anonymous emergency calling.)
2014-03-25
09 Stephen Farrell
[Ballot comment]

- The title is misleading. I expected to be told how to
do something or how someone had done something but
instead the …
[Ballot comment]

- The title is misleading. I expected to be told how to
do something or how someone had done something but
instead the draft actually discusses pros and cons of
many ways of providing location information for emergency
calls. And no firm conclusion is reached. So I suggest a
tile such as "Issues with Trusting Location" would be a
more appropriate title.

- section 2: The adversary model seems a bit mixed up.
You say you're only considering the end host model but
yet make a number of references to other nodes cheating.
(For example, point 3 in 2.1 where the LIS cheating is
mentioned.)

- section 4 talks about a location that has "been
conveyed securely" but section 3 has just before that
told me that there are no "secure" options at all. I
don't see how you can hold both positions in one
document.
2014-03-25
09 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2014-03-25
09 Spencer Dawkins
[Ballot comment]
I like this draft. It's quite clear.

I have some comments that I'd like you to consider along with other comments you may …
[Ballot comment]
I like this draft. It's quite clear.

I have some comments that I'd like you to consider along with other comments you may receive.

In this text:

1.  Introduction

  Since prank emergency calls can endanger bystanders or emergency
  services personnel, or divert resources away from legitimate
  emergencies, they can be life threatening.  A particularly dangerous
  form of prank call is "swatting" - a prank emergency call that draws
  a response from law enforcement (e.g. a fake hostage situation that
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Most television viewers in the US would understand the danger, but I wonder if readers throughout the world would have the same understanding. I might have suggested "a response from law enforcement prepared for a violent confrontation" or something ("brandishing automatic weapons").

  results in dispatching of a "Special Weapons And Tactics" (SWAT)
  team).  In 2008 the Federal Bureau of Investigation (FBI) issued a
  warning [Swatting] about an increase in the frequency and
  sophistication of these attacks.

In this text:

2.  Threats

  Since we do not focus
  on attackers gaining control of infrastructure elements (e.g.,
  location servers, call route servers) or the emergency services IP
  network, the threats arise from end hosts. 

I am not suggesting any additional work to cover threats that don't arise from end hosts, and I'm not challenging this scope, but you might consider adding a sentence (perhaps at the end of this section) explaining why you chose this scope (because that's where most threats come from? Because subverting infrastucture/emergency services IP networks is hard, because defending against threats that don't originate from end hosts require different countermeasures ... I'd believe any of these or anything else that's plausible).

In this text:

3.2.  Location by Reference

I confess to thinking about the issue because of another doc on this week's telechat agenda, but I agree with your suggestion here

  For location-by-reference, the location server needs to maintain one
  or several URIs for each target, timing out these URIs after a
  certain amount of time.  References need to expire to prevent the
  recipient of such a Uniform Resource Locator (URL) from being able to
  permanently track a host and to offer garbage collection
  functionality for the location server.

and wonder if you should also suggest not reusing URLs for some period of time (especially if that qualifies as location-swapping, listed as a threat, and you're using "Authorization by Possession" of the URL).

In this text:

4.  Location Trust Assessment

  Where attacks are frequent and continuous, automated mechanisms are
  required.  For example, it might be valuable to develop mechanisms to
  exchange audit trails information in a standardized format between
  ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish
  potentially fraudulent emergency calls from real emergencies.  While
  a Completely Automated Public Touring test to tell Computers and
                                ^^^^^^^

I'm betting that's "Turing" ...

  Humans Apart (CAPTCHA) may be applied to suspicious calls to lower
  the risk from bot-nets, this is quite controversial for emergency
  services, due to the risk of delaying or rejecting valid calls.

In this text:

5.  Security Considerations

  However, within an IP-based emergency services a number of these
  attacks become much easier to mount.  Emergency services have three
  finite resources subject to denial of service attacks:  the network
  and server infrastructure, call takers and dispatchers, and the first
  responders, such as fire fighters and police officers.  Protecting
  the network infrastructure is similar to protecting other high-value
  service providers, except that location information may be used to
  filter call setup requests, to weed out requests that are out of
  area.  PSAPs even for large cities may only have a handful of PSAP
  call takers on duty, so even if they can, by questioning the caller,
                                  ^^^^
  eliminate a lot of prank calls, they are quickly overwhelmed by even
                                  ^^^^

are the "they"s referring to the same thing? "PSAPs" and "call takers" are both plural, so this isn't easy to parse.


  a small-scale attack.  Finally, first responder resources are scarce,
  particularly during mass-casualty events.
2014-03-25
09 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2014-03-25
09 Brian Weis Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Brian Weis.
2014-03-24
09 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-03-23
09 Alissa Cooper
[Ballot comment]
One extra comment at the end that I failed to include in my first mail ...

Section 1:

I would suggest using the …
[Ballot comment]
One extra comment at the end that I failed to include in my first mail ...

Section 1:

I would suggest using the "Target" definition from RFC 6280 (unless there's an explicit reason to use the older definition).

Section 3.1:

"With location signing, a location server signs the location
  information before it is sent to the end host, (the entity subject to
  the location determination process).  The signed location information
  is then verified by the location recipient and not by the target."
 
This explanation is unclear. I think this is what was meant here:

"With location signing, a location server signs the location
  information before it is sent to the Target.  The signed location information
  is then sent to the location recipient, who verifies it."
 
Also, I thought we stopped using the term "Geopriv Using Protocol" a long time ago. Please find some other term ("protocol that conveys location" would do the trick I think). Same comment in Section 3.2.

Section 3.2:

The specification of the DHCP location-by-reference URI option is not moving forward, so reference to it should be removed.
2014-03-23
09 Alissa Cooper Ballot comment text updated for Alissa Cooper
2014-03-23
09 Alissa Cooper
[Ballot comment]
Section 1:

I would suggest using the "Target" definition from RFC 6280 (unless there's an explicit reason to use the older definition).

Section …
[Ballot comment]
Section 1:

I would suggest using the "Target" definition from RFC 6280 (unless there's an explicit reason to use the older definition).

Section 3.1:

"With location signing, a location server signs the location
  information before it is sent to the end host, (the entity subject to
  the location determination process).  The signed location information
  is then verified by the location recipient and not by the target."
 
This explanation is unclear. I think this is what was meant here:

"With location signing, a location server signs the location
  information before it is sent to the Target.  The signed location information
  is then sent to the location recipient, who verifies it."
 
Also, I thought we stopped using the term "Geopriv Using Protocol" a long time ago. Please find some other term ("protocol that conveys location" would do the trick I think). Same comment in Section 3.2.
2014-03-23
09 Alissa Cooper Ballot comment text updated for Alissa Cooper
2014-03-21
09 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-03-20
09 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2014-03-20
09 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2014-03-20
09 Tina Tsou Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Bert Wijnen.
2014-03-17
09 Adrian Farrel
[Ballot comment]
I have no objection to the publication of this document.

---

I'm interested in two scenarios. The first is whether we would ever …
[Ballot comment]
I have no objection to the publication of this document.

---

I'm interested in two scenarios. The first is whether we would ever
reach a position where an emergency call that did not contain
authenticatable location information would be discarded or treated as
less urgent: "90 year-old widow burns to death because she used an old
telephone". The second is whether there is a risk of false negatives
that might lead the PSAP to mark a call as containing false information
when it is in fact genuine: "Screw-up at high tech call center leads to                             
death of 3 year-old girl".

Perhaps this is covered by Section 4's
  if automated
  location information is understood to be highly suspect, a call taker
  can put more effort into obtaining location information from the
  caller.

Maybe you could make this statement (adding "or absent") in the
Introduction.

But note that the thrust of the document is that if the location info is
suspect then the whole call is suspect. So perhaps you need to modify
this text as...

  if automated
  location information is understood to be highly suspect or is absent,
  a call taker can put more effort into verifying the authenticity of
  the call and to obtaining location information from the caller.

---

A paragraph in the Introduction gives a false impression:

  EENA [EENA] has attempted to define terminology and describe best
  current practices for dealing with false emergency calls, which in
  certain European countries can constitute as much as 70% of all
  emergency calls.  Reducing the number of prank calls represents a
  challenge, since emergency services authorities in most countries are
  required to answer every call (whenever possible).  Where the caller
  cannot be identified, the ability to prosecute is limited.

This leaves the reader believing that 70% of of all emergency calls are
pranks, where the definition of "false" in the referenced document is
quite different. Since the purpose of this work has two prongs
(correctly locating a real emergency caller, and helping to identify
prank calls - with the possibility of taking additional action) I
think that the reference to 70% could be reasonably removed.

---

In the Introduction...

  Ideally, a call taker at a Public Service Answering Point (PSAP)
  should be put in the position to assess, in real-time, the level of
  trust that can be placed on the information provided within a call.
  This includes automated location conveyed along with the call and
  location information communicated by the caller, as well as identity
  information about the caller.  Where real-time assessment is not
  possible, it is important to be able to determine the source of the
  call in a post-mortem, so as to be able to enforce accountability.

Can "identity information about the caller" really be determined? Do
you mean "identity of the calling equipment?

Do you really mean "post-mortem"? That sounds a bit dramatic. Maybe
"after the fact".

--

The term PIDF-LO is used before it is expanded in Section 2.1.

---

LSP
Great. Just what we needed. More meanings for the same old acronyms.
Would you consider including a reference to RFC 5513?

---

Shouldn't "Identity Spoofing" appear in Section 1.1?

---

In Section 3
                                   
  This section presents three mechanisms which can be used to convey
  location securely

Is this exactly what you meant to say? "Convey securely" implies to me
"protect against tampering on wire" and possibly "protect against
snooping". but you are talking about source-signing which is equally
about making the information authenticatable.
2014-03-17
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-03-17
09 Bernard Aboba IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-03-17
09 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-09.txt
2014-03-12
08 Alissa Cooper IESG state changed to IESG Evaluation from Waiting for Writeup
2014-03-12
08 Alissa Cooper Placed on agenda for telechat - 2014-03-27
2014-03-12
08 Alissa Cooper Ballot has been issued
2014-03-12
08 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2014-03-12
08 Alissa Cooper Created "Approve" ballot
2014-03-11
08 Alissa Cooper Ballot writeup was changed
2014-03-05
08 Amy Vezza Shepherding AD changed to Alissa Cooper
2014-03-05
08 Meral Shirazipour Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour.
2014-02-28
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2014-02-20
08 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2014-02-20
08 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2014-02-20
08 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2014-02-20
08 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ecrit-trustworthy-location-08, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ecrit-trustworthy-location-08, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion. 

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if authors prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.
2014-02-20
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Brian Weis
2014-02-20
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Brian Weis
2014-02-17
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Bert Wijnen
2014-02-17
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Bert Wijnen
2014-02-14
08 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-02-14
08 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Trustworthy Location) to Informational RFC …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Trustworthy Location) to Informational RFC


The IESG has received a request from the Emergency Context Resolution
with Internet Technologies WG (ecrit) to consider the following document:
- 'Trustworthy Location'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-02-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  For some location-based applications, such as emergency calling or
  roadside assistance, the trustworthiness of location information is
  critically important.

  This document describes how to convey location in a manner that is
  inherently secure and reliable.  It also provides guidelines for
  assessing the trustworthiness of location information.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2181/



2014-02-14
08 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-02-14
08 Richard Barnes Last call was requested
2014-02-14
08 Richard Barnes Ballot approval text was generated
2014-02-14
08 Richard Barnes IESG state changed to Last Call Requested from Publication Requested
2014-02-14
08 Richard Barnes Last call announcement was generated
2014-02-14
08 Richard Barnes Last call announcement was generated
2014-02-14
08 Richard Barnes Ballot writeup was changed
2014-02-14
08 Richard Barnes Ballot writeup was generated
2014-02-03
08 Cindy Morgan
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of …
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

RFC type being requested for this draft is Informational, since the draft provides guidelines.  The title page lists it currently as "Informational".


(2) 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

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

[Abstract]
  For some location-based applications, such as emergency calling or
  roadside assistance, the trustworthiness of location information is
  critically important.

  This document describes how to convey location in a manner that is
  inherently secure and reliable.  It also provides guidelines for
  assessing the trustworthiness of location information.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There was healthy work group participation in compiling the details that make up the guidelines within the draft.  There were no significant controversies noted on the list, and all dialogues were efficiently attended to with during the development stage. A successful development progression is documented in the ECRIT wg minutes and in email list archives.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

No existing implementations are known to exist.  There have been several vendors that have been involved in the development and review of the document.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document shepherd is Roger Marshall.
Area Director is Richard Barnes.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Careful review by the document shepherd following WGLC.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.


(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

None noted.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, I have received confirmation of "No IPR to be disclosed" from each author.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Yes, IPR has been filed at https://datatracker.ietf.org/ipr/2181/.  No work group discussion has taken place around this ipr item after notification posted.


(9) 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 strong work group consensus to move this document forward to RFC status.


(10) 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 is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None found.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no MIB, media, or new URI types referenced to in this document.

(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) 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 plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No referenced RFCs will change in status due to publication of this document.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

All IANA registry requirements have been met.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable.
2014-02-03
08 Cindy Morgan Document shepherd changed to Roger Marshall
2014-02-03
08 Cindy Morgan Intended Status changed to Informational
2014-02-03
08 Cindy Morgan IESG process started in state Publication Requested
2014-02-03
08 (System) Earlier history may be found in the Comment Log for /doc/draft-tschofenig-ecrit-trustworthy-location/
2014-02-03
08 Cindy Morgan Working group state set to Submitted to IESG for Publication
2014-01-21
08 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-08.txt
2013-09-04
(System) Posted related IPR disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-trustworthy-location-07
2013-07-30
07 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-07.txt
2013-07-15
06 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-06.txt
2013-03-13
05 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-05.txt
2012-10-22
04 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-04.txt
2012-04-04
03 Bernard Aboba New version available: draft-ietf-ecrit-trustworthy-location-03.txt
2011-11-25
02 (System) Document has expired
2011-05-24
02 (System) New version available: draft-ietf-ecrit-trustworthy-location-02.txt
2010-10-25
01 (System) New version available: draft-ietf-ecrit-trustworthy-location-01.txt
2010-09-21
00 (System) New version available: draft-ietf-ecrit-trustworthy-location-00.txt