Additional Data Related to an Emergency Call
draft-ietf-ecrit-additional-data-38

[Ballot comment]

Thanks for handling my discuss points.

-35 handled most of the stuff below just fine but I left
the comments there. I didn't check -36 for that.

- abstract: the "or by reference" point is made twice
in the abstract

- intro: floor plans? HVAC status? really? Why not
contact lists? proximity of friends? That (or
inferring as much) seems to me to be going too far, if
applied to all calls. I'd say just saying that this
could be extended in future by other standards-track
specifications is enough. (See also discuss points above)

- intro: Wedding anniversary? That's surely not
relevant to a PSAP.

- figure 5: "prison" is out of context here, I'd suggest
deleting it. If not, why not add hospital, power station
and many other kinds of building? There may be some
country specific issue or technical here, but labelling
that with "prison" seems inappropriate to me.

- 4.3.8: sorry I don't get the privacy argument, can
you try explain it to me?  (I didn't know it was
possible to tempt an implementation, so the language
there could be improved for sure:-)

- section 5: good that this is HTTPS only. I think
provisioning the PKI for such a thing is easily done
these days and is rightly not optional. It might be
useful to say that TLS here needs to follow BCP195.  I
agree with the earlier comment that you should be
clear as to when mutually authenticated TLS is
required. The secdir review [2] also raised similar
issues and it'd be good to see responses to that too.
(Yes, that review only arrived today so it's entirely
reasonable to not have responded so far.)

  [2] https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html

- section 8: the sizes of the various additional data
items here could be characteristic and leak value
information regardless of TLS or not-TLS - perhaps add
a warning that these may enable relatively simple
traffic analysis. And wouldn't it be nice if someone
had done the analysis of this potential vulnerability?
This is btw a real issue - recall that avatar icon
image size was usable to identify 30+% of contacts in
one social network even over TLS, but before the
provider canonicalised the avatar image sizes.

- Thanks for section 9. Good job.

[Ballot discuss]

I've two things I'd like to chat about. (Note: I'm not trying
here to insist on my preferred outcome, but I would like to
have the discussion or else be pointed at where the WG
already did that.)

(1) section 3: You say these MAY be used.  I'm not
sure that's a good option.  I think the data
minimisation recommendations argued for in RFC6973 and
RFC7258 would argue to add a MUST NOT. For example,
saying that these additional data MUST NOT be sent in
any non-emergency call without explicit user
permission on a per-call basis or something similar?
I have to admit I'm nervous that defining all of these
may mean that some UA somewhere starts sending some of
them in other calls without asking. A restriction
along those lines would also be more in line with
webrtc too perhaps. But maybe this was discussed in
the WG, having considered those privacy issues - was
it? Either way, would adding such a "MUST NOT except
if..." be a good plan?  4.3.4 is a good example of the
kind of thing I'd not want easily emitted in a call.

(2) cleared

[Ballot comment]

-35 handled most of the stuff below just fine but I left
the comments there.

- abstract: the "or by reference" point is made twice
in the abstract

- intro: floor plans? HVAC status? really? Why not
contact lists? proximity of friends? That (or
inferring as much) seems to me to be going too far, if
applied to all calls. I'd say just saying that this
could be extended in future by other standards-track
specifications is enough. (See also discuss points above)

- intro: Wedding anniversary? That's surely not
relevant to a PSAP.

- figure 5: "prison" is out of context here, I'd suggest
deleting it. If not, why not add hospital, power station
and many other kinds of building? There may be some
country specific issue or technical here, but labelling
that with "prison" seems inappropriate to me.

- 4.3.8: sorry I don't get the privacy argument, can
you try explain it to me?  (I didn't know it was
possible to tempt an implementation, so the language
there could be improved for sure:-)

- section 5: good that this is HTTPS only. I think
provisioning the PKI for such a thing is easily done
these days and is rightly not optional. It might be
useful to say that TLS here needs to follow BCP195.  I
agree with the earlier comment that you should be
clear as to when mutually authenticated TLS is
required. The secdir review [2] also raised similar
issues and it'd be good to see responses to that too.
(Yes, that review only arrived today so it's entirely
reasonable to not have responded so far.)

  [2] https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html

- section 8: the sizes of the various additional data
items here could be characteristic and leak value
information regardless of TLS or not-TLS - perhaps add
a warning that these may enable relatively simple
traffic analysis. And wouldn't it be nice if someone
had done the analysis of this potential vulnerability?
This is btw a real issue - recall that avatar icon
image size was usable to identify 30+% of contacts in
one social network even over TLS, but before the
provider canonicalised the avatar image sizes.

- Thanks for section 9. Good job.

[Ballot comment]
Thanks so much for addressing all my comments -- version -35 looks really good.

A minor thing that the RFC Editor will correct anyway, but if you happen to do another round of changes: You have "mime" in lower case in three places (in Sections 4.2, 4.3, and 4.5), and they should be upper-cased.

[Ballot comment]
A Gen-ART review arrived from Francis Dupont a while ago. Hopefully the authors can go over the comments and see what needs addressing, before the draft is approved.

[Ballot comment]
I note that Stephen hasn't cleared his Discuss yet, so I'll let that play out (and thanks to all who are busily Discussing it), but just for the record, I'm also confused between

  The intent
  is that every emergency call carry the information described here
  using the mechanisms described here.

and (paraphrasing)

"we aren't the experts on extending this mechanism, and we can't say who is, but there's more than one set of experts"

This tussle sounds like a fork waiting to happen.

Is that going to be a problem? One answer could be "if it is, we aren't the ones who are going to have to solve it", but I thought I'd ask.

[Ballot comment]
Thanks for your work on this document and the detailed security and privacy considerations balanced against safety risks.  I don't have any questions besides those already asked, but do appreciate the detailed security and privacy recommendations with the understanding of the need to balance risk (to the caller) for this work.

[Ballot comment]
I have no objections to the publication of this document.

- I find text like "Optional for blocks supplied by the originating device, mandatory otherwise" in multiple places in this specification.  Is there a reason for not saying "originating devices MAY supply this information, all other entities MUST supply this information" or some such?

- I look forward to the resolution of Stephen's DISCUSS points.

[Ballot discuss]
Two things are incorrect and need fixing:

---- In Section 4, you have "tel" and "TYPE", and "property" and "parameter" reversed in the explanation about the "main" parameter value.  The sentence is also confusingly worded.  Try this (and see also my comments on this bit, below):

NEW
  This document adds a new parameter value called "main" to the
  "TYPE" parameter of the "tel" property.
END

---- In Section 6, there are problems in the MIME structure in the examples (figures 16 and 17).

1. The XML content should be indented at least as much as the SIP headers, so you should either make sure that all XML lines are indented at least 6 characters, or you should make the SIP headers be indented only by 3.

2. There should not be a blank line between the Content-Type and Content-Length headers.

3. There should not be a blank line after each boundary line; the part headers should start immediately, as the first blank line ends the headers.

4. There should be a blank line between the Content-Disposition header and the XML content; that blank line ends the part headers and signals the start of the part body.

5. The intermediate boundary lines should not have the trailing "--"; that's reserved for the ending boundary.  The intermediates should all be "--boundary1".

6. Figure 17 is missing the ending boundary, "--boundary1--", at the very end of the figure.

[Ballot comment]
Throughout the document:
The current term is "media type", not "MIME type".  It would be good if you can change that throughout the document.

-- Section 3 --
A tiny, tiny point: I don't think the MAY in the last sentence is really a 2119 key word, and suggest making it lower case.

-- Section 4 --

  In an xCard there is no way to
  specify a "main" telephone number.  These numbers are useful to
  emergency responders who are called to a large enterprise.  This
  document adds a new property value to the "tel" property of the TYPE
  parameter called "main".

This doesn't explain sufficiently what you're after.  I initially wondered why the PREF parameter didn't give you what you need (PREF=1, this is my main phone number).  It was only when I read the registration in Section 10 that I understood.  I'd suggest a value other than "main", but I can't think of one right away.  At the least, please add more text here to explain what you mean by "main".

I'll also note that none of the examples include the new "main" parameter value.  Given that you're creating the value, it might be good to show it in use.

-- Section 4.1.5 --

      The Data
      Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format
      fully specified with country code.  If a TEL URI is not available,
      it MAY be a generic SIP URI.

2119 key word problem @1: "you SHOULD do X, but you MAY do Y instead."  MAY contradicts the SHOULD.  It's not so bad here because your "if" restricts the MAY (Section 5.3 isn't that way; see below), but I'd prefer it if you'd change it to something like "If a TEL URI is not available, a generic SIP URI is acceptable."  Or perhaps "A generic SIP URI is acceptable only if a TEL URI is not available," which is a little stronger.

-- Section 4.4.2 --

      If more than one  property is provided, a parameter from the
      vCard Property Value registry MUST be specified on each .

Do you really want that MUST, rather than a SHOULD?  Are you really saying that if there are multiple phone numbers but I don't know their TYPE values, it's better to pick one and send only that one than it is to send you all of them just in case?

-- Section 5.1 --

  The data may also be supplied by value in any SIP request or response
  method that is permitted to contain a body (i.e., not a BYE request).

Is BYE the only SIP request that can't contain a body?  Or should that be "e.g."?  (I'm asking; I don't know the answer.)

-- Section 5.3 --

  It is RECOMMENDED that access networks supply the data specified in
  this document by reference, but they MAY provide the data by value.

Here's the SHOULD/MAY problem without an "if" to mitigate it.  In this case, I suggest explaining:

NEW
  It is RECOMMENDED that access networks supply the data specified in
  this document by reference.  While it's permissible to provide the
  data by value, this can expose private information [and/or whatever
  other explanation].
END

-- Section 10.1 --
Thanks for providing guidance to the expert reviewers; that's really helpful.

-- Section 11 --
Is the comma in "Christian, Militeau" spurious?

-- Appendix A --
You appear to have turned the RELAX NG schema from RFC 6351 into an XML schema and put it here, but then labelled it as informational -- a hedge, I guess, in case there's a mistake in this version.  Why does it need to be included here?  And how much review has it actually had, to make sure that there weren't any mistakes in the conversion?

[Ballot discuss]

I've two things I'd like to chat about. (Note: I'm not trying
here to insist on my preferred outcome, but I would like to
have the discussion or else be pointed at where the WG
already did that.)

(1) section 3: You say these MAY be used.  I'm not
sure that's a good option.  I think the data
minimisation recommendations argued for in RFC6973 and
RFC7258 would argue to add a MUST NOT. For example,
saying that these additional data MUST NOT be sent in
any non-emergency call without explicit user
permission on a per-call basis or something similar?
I have to admit I'm nervous that defining all of these
may mean that some UA somewhere starts sending some of
them in other calls without asking. A restriction
along those lines would also be more in line with
webrtc too perhaps. But maybe this was discussed in
the WG, having considered those privacy issues - was
it? Either way, would adding such a "MUST NOT except
if..." be a good plan?  4.3.4 is a good example of the
kind of thing I'd not want easily emitted in a call.

(2) I'd like to (perhaps briefly) argue that the
registries here should require more than expert
review. Extensibility in dealing with what will
inevitably be highly privacy sensitive data structures
that are vulnerable to misuse once registered seems to
perhaps call for a more stringent registration regime.
The document itself also argues (in 4.3.7) that adding
new kinds of data here can be counter productive for
emergency call handling, so being more conservative in
what we add seems unusually correct here. I'd like to
suggest we require standards track for extensions.
The following very recent -00 draft [1] makes some
related arguments (but of course has no standing in
the IETF so is just offered as a way to avoid
repeating some arguments, not as an appeal to
authority.)

  [1] https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00

[Ballot comment]

- abstract: the "or by reference" point is made twice
in the abstract

- intro: floor plans? HVAC status? really? Why not
contact lists? proximity of friends? That (or
inferring as much) seems to me to be going too far, if
applied to all calls. I'd say just saying that this
could be extended in future by other standards-track
specifications is enough. (See also discuss points above)

- intro: Wedding anniversary? That's surely not
relevant to a PSAP.

- figure 5: "prison" is out of context here, I'd suggest
deleting it. If not, why not add hospital, power station
and many other kinds of building? There may be some
country specific issue or technical here, but labelling
that with "prison" seems inappropriate to me.

- 4.3.8: sorry I don't get the privacy argument, can
you try explain it to me?  (I didn't know it was
possible to tempt an implementation, so the language
there could be improved for sure:-)

- section 5: good that this is HTTPS only. I think
provisioning the PKI for such a thing is easily done
these days and is rightly not optional. It might be
useful to say that TLS here needs to follow BCP195.  I
agree with the earlier comment that you should be
clear as to when mutually authenticated TLS is
required. The secdir review [2] also raised similar
issues and it'd be good to see responses to that too.
(Yes, that review only arrived today so it's entirely
reasonable to not have responded so far.)

  [2] https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html

- section 8: the sizes of the various additional data
items here could be characteristic and leak value
information regardless of TLS or not-TLS - perhaps add
a warning that these may enable relatively simple
traffic analysis. And wouldn't it be nice if someone
had done the analysis of this potential vulnerability?
This is btw a real issue - recall that avatar icon
image size was usable to identify 30+% of contacts in
one social network even over TLS, but before the
provider canonicalised the avatar image sizes.

- Thanks for section 9. Good job.

[Ballot comment]
Given that the intent of the document “is that every emergency call carry the information described here using the mechanisms described here”, and that additional information is being introduced as ‘Required’, shouldn’t it update RFC6443 and/or at least RFC6881?

[Ballot comment]
[Edit: I asked a question below about what happens if you dereference a block, and find the URL points to something other than what you expected. On reflection, I should expand that  to ask how dereferencing errors should be handled in general.]

This draft was clearly lots of work; thanks for making it happen. However, I have a number of comments:

The shepherd’s writeup indicates that no XML or media type reviews were
required—but this document contains a lot of XML (examples and schema),
and a number of media type registrations. Is that an error in the writeup,
or have those reviews been skipped?

This draft implicitly assumes that the emergency calls are signaled with
SIP. I don't dispute that assumption, but I think it should it's worth a
paragraph stating it explicitly.

-- section 2, 2nd paragraph:
Are there any considerations for services provided with no "company" or
"service provider" behind them? For example, lets say an individual hosts
some VoIP related services for her own use (e.g. a SIP registrar, maybe a
stun/turn server,etc) Are those in scope? I'm guessing not, since they would
be unlikely to be registered with NENA, but it would be worth saying that
explicitly.

-- 3:
Is there a critical need for the bit about "certain private-use
situations"? That seems like license for abuse, without more elaboration
about "prexisting relationship" and "privacy issues addressed".

-- 4, third paragraph from end:
Can you elaborate on what you mean by "at
the same time"? Does that mean for the same call? Occurring in some interval
of time ?

-- 4.1.4
Is a provider limited to one type? If the same provider provides
services in multiple categories,  would they create multiple instances?

-- 4.1.5:
Do you intend 24x7 support to be a prerequisite to be a data
provider?

-- 4.1.7, Description: "Although multiple  elements may be contained
in a structure only one  element SHOULD be provided.  If more than
one appears, the first SHOULD be used."
When might it be reasonable to violate either of these SHOULDs? If the
receiver should only look at the first entry why are multiple entries
allowed at all?

Also, it seems like there are vcard fields that are not useful to this
purpose and might still have privacy implications. Do we really need people
to send everything?

-- 4.2.1, How Used..., last sentence:
The term "wireless "needs more
precision if you're going to use it in a 2119 expression. With a Wi-Fi
handset connected to a wired Internet service count as wireless? How about a
cordless phone?

-- Figure 5:
-Can the list of wireless types change over time?
-I don't understand the full definition of "temp". Are these terms defined somewhere?
-Do you really want "POTS" vs "PSTN"?
-Is VoIP intentionally limited to OTT services?

-- 4.3.3:
What if the device model designation is not a number?

-- 5, list item 1: "The "purpose" parameter also indicates the kind of data
(by its MIME subtype) that is available at the URI"
What happens if the URL points to something other than the indicated thing?

- list item 2, last sentence:
I gathered this section was an overview, since
you have detailed procedures later. Please consider moving 2119 language to
that section.

-- Section 5, last paragraph: "only blocks in the registry are permitted to
be sent using the mechanisms specified in this document"
Are implementations supposed to check the registry at run time? (Also, that
language sounds like it should be normative.)

-- 5.1, last paragraph: "More than one Call-Info header field with a purpose
value starting with ’EmergencyCallData’ can be expected, but at least one
MUST be provided.  The device MUST provide one if it knows no service
provider is in the path of the call."
What's the scope of the first MUST? Emergency calls? Is it possible the
device doesn't know whether there is a service provider in the path? Should
this say it MUST insert unless it knows there is a service provider in tHe
path?

-- 8:
It might be worth discussing the potential harm done by a malicious proxy
modifying a data element, or a compromised data source return incorrect
information when dereferencing a URL.

The first paragraph REQUIRES verification of requester credentials, but does
specify the form of those credentials. Subsequent text talks about
client-certs and PKI verification. Are other forms of credentials allows?
(HTTP-digest, application level logins, etc). If client-certs are required,
please say that explicitly.

- "PSAPs and responder agencies SHOULD deploy a PKI "
When might they not? What if they don't?

- "emergency services authorities could obtain a credential from the DNS
entry of the domain"
Can you elaborate on that or cite something?

- paragraph starting with "Much of the information supplied by service
providers and devices is private and confidential":
Seems like that should go in the privacy considerations. (And probably also
the intro.)

-- section 10:
Many of the registry policies require experts to access
whether an organization might be "legitimate" or "relevant". Are these
reasonable expectations on the DEs? (I don't know the answer.)

Nits and Editorial Comments:

-- 4.2.1, Description: Currently, the only valid entries are...
Current as of when?  I suggest "The initially valid entries are..."

-- 4.2.1, How Used... : "... service provider does not know ..."
Does not know...what?  (That's part of a long, convoluted sentence. Please consider
breaking it into simpler sentences.)

"... it is known to be valuable."
Known by whom?

-- 4.3.1, Description: "It is possible to receive two Additional Data
Associated with a Call data structures,..." (Occurs in several places.)
The naming is confusing. It's easy to read "additional data associated with..."
as it's plain English meaning, rather than as a name. I suggest doing
something more distinctive than capital letters. Perhaps quotes, or even an
abbreviation.

-- 4.3.7: That seems odd for this to be a subsection of the device
information function.

-- section 5:
It seems awkard to use a numbered list for elements that are
close to a page long each. This forces each to be a single, overlong
paragraph. Please consider subsections.

-- section 5, list item 2: "circumstances about the provision of the location"
I'm not sure I understand the meaning of "provision" in this
context.
- Sentence starting with: "When the access network provider"
This sentence provides context information that would have been useful to have at
the start of the section.

-- 5.4, 2nd paragraph:
I think people are going to be confused and look for
"by-reference" in 3204 or 3459. It might be worth re-citing 5621.

--10:

Some sections reference tables from other sections, and some include the
tables directly. It would be nice to be consistent, one way or the other.

[Ballot comment]
This draft was clearly lots of work; thanks for making it happen. However, I have a number of comments:

The shepherd’s writeup indicates that no XML or media type reviews were
required—but this document contains a lot of XML (examples and schema),
and a number of media type registrations. Is that an error in the writeup,
or have those reviews been skipped?

This draft implicitly assumes that the emergency calls are signaled with
SIP. I don't dispute that assumption, but I think it should it's worth a
paragraph stating it explicitly.

-- section 2, 2nd paragraph:
Are there any considerations for services provided with no "company" or
"service provider" behind them? For example, lets say an individual hosts
some VoIP related services for her own use (e.g. a SIP registrar, maybe a
stun/turn server,etc) Are those in scope? I'm guessing not, since they would
be unlikely to be registered with NENA, but it would be worth saying that
explicitly.

-- 3:
Is there a critical need for the bit about "certain private-use
situations"? That seems like license for abuse, without more elaboration
about "prexisting relationship" and "privacy issues addressed".

-- 4, third paragraph from end:
Can you elaborate on what you mean by "at
the same time"? Does that mean for the same call? Occurring in some interval
of time ?

-- 4.1.4
Is a provider limited to one type? If the same provider provides
services in multiple categories,  would they create multiple instances?

-- 4.1.5:
Do you intend 24x7 support to be a prerequisite to be a data
provider?

-- 4.1.7, Description: "Although multiple  elements may be contained
in a structure only one  element SHOULD be provided.  If more than
one appears, the first SHOULD be used."
When might it be reasonable to violate either of these SHOULDs? If the
receiver should only look at the first entry why are multiple entries
allowed at all?

Also, it seems like there are vcard fields that are not useful to this
purpose and might still have privacy implications. Do we really need people
to send everything?

-- 4.2.1, How Used..., last sentence:
The term "wireless "needs more
precision if you're going to use it in a 2119 expression. With a Wi-Fi
handset connected to a wired Internet service count as wireless? How about a
cordless phone?

-- Figure 5:
-Can the list of wireless types change over time?
-I don't understand the full definition of "temp". Are these terms defined somewhere?
-Do you really want "POTS" vs "PSTN"?
-Is VoIP intentionally limited to OTT services?

-- 4.3.3:
What if the device model designation is not a number?

-- 5, list item 1: "The "purpose" parameter also indicates the kind of data
(by its MIME subtype) that is available at the URI"
What happens if the URL points to something other than the indicated thing?

- list item 2, last sentence:
I gathered this section was an overview, since
you have detailed procedures later. Please consider moving 2119 language to
that section.

-- Section 5, last paragraph: "only blocks in the registry are permitted to
be sent using the mechanisms specified in this document"
Are implementations supposed to check the registry at run time? (Also, that
language sounds like it should be normative.)

-- 5.1, last paragraph: "More than one Call-Info header field with a purpose
value starting with ’EmergencyCallData’ can be expected, but at least one
MUST be provided.  The device MUST provide one if it knows no service
provider is in the path of the call."
What's the scope of the first MUST? Emergency calls? Is it possible the
device doesn't know whether there is a service provider in the path? Should
this say it MUST insert unless it knows there is a service provider in tHe
path?

-- 8:
It might be worth discussing the potential harm done by a malicious proxy
modifying a data element, or a compromised data source return incorrect
information when dereferencing a URL.

The first paragraph REQUIRES verification of requester credentials, but does
specify the form of those credentials. Subsequent text talks about
client-certs and PKI verification. Are other forms of credentials allows?
(HTTP-digest, application level logins, etc). If client-certs are required,
please say that explicitly.

- "PSAPs and responder agencies SHOULD deploy a PKI "
When might they not? What if they don't?

- "emergency services authorities could obtain a credential from the DNS
entry of the domain"
Can you elaborate on that or cite something?

- paragraph starting with "Much of the information supplied by service
providers and devices is private and confidential":
Seems like that should go in the privacy considerations. (And probably also
the intro.)

-- section 10:
Many of the registry policies require experts to access
whether an organization might be "legitimate" or "relevant". Are these
reasonable expectations on the DEs? (I don't know the answer.)

Nits and Editorial Comments:

-- 4.2.1, Description: Currently, the only valid entries are...
Current as of when?  I suggest "The initially valid entries are..."

-- 4.2.1, How Used... : "... service provider does not know ..."
Does not know...what?  (That's part of a long, convoluted sentence. Please consider
breaking it into simpler sentences.)

"... it is known to be valuable."
Known by whom?

-- 4.3.1, Description: "It is possible to receive two Additional Data
Associated with a Call data structures,..." (Occurs in several places.)
The naming is confusing. It's easy to read "additional data associated with..."
as it's plain English meaning, rather than as a name. I suggest doing
something more distinctive than capital letters. Perhaps quotes, or even an
abbreviation.

-- 4.3.7: That seems odd for this to be a subsection of the device
information function.

-- section 5:
It seems awkard to use a numbered list for elements that are
close to a page long each. This forces each to be a single, overlong
paragraph. Please consider subsections.

-- section 5, list item 2: "circumstances about the provision of the location"
I'm not sure I understand the meaning of "provision" in this
context.
- Sentence starting with: "When the access network provider"
This sentence provides context information that would have been useful to have at
the start of the section.

-- 5.4, 2nd paragraph:
I think people are going to be confused and look for
"by-reference" in 3204 or 3459. It might be worth re-citing 5621.

--10:

Some sections reference tables from other sections, and some include the
tables directly. It would be nice to be consistent, one way or the other.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ecrit-additional-data-33, and its reviewer has questions about several of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval, this document makes a significant request for actions by IANA. This detailed note provides IANA's understanding of the requests being made in the document. There are 15 actions detailed in this note. IANA understands that these 15 actions are the only ones required upon approval of this document.

This document requests the creation of a new registry grouping called the "Emergency Call Additional Data" registry. In this new registry, eight new subregistries are to be created. In the current document, IANA understands these to be named:

'Additional Call Data Provider ID Series'
'Additional Call Service Environment'
'Additional Call Service Type'
'Additional Call Service Mobility'
'Service Provider Type'
'Device Classification'
'Additional Call Data Device ID Type'
'Device/Service Data Type Registry'

Upon subsequent discussion with the authors, it has been suggested that these be renamed to the following:

-> Provider ID Series
-> Service Environment
-> Service Type
-> Service Mobility
-> Service Provider Type
-> Device Classification
-> Device ID Type
-> Device/Service Data Type

QUESTION: Typically the last field in a registry is a "Reference" column that's used to list specifications and/or contacts. A few of the registries below already have a "Reference" or "Specification" column. For those that don't, can this document be listed as a reference for all of the registrations? (It's not uncommon for the document that creates the registry to be listed as the reference.)

This is the list of IANA actions, as we understand them:

First, a new subregistry will be created in the "Emergency Call Additional Data" registry called the Provider ID Series subregistry. This registry will be maintained via Expert Review as defined in RFC 5226.

These are the initial registrations:

+-----------+--------------------------+----------------------+
| Name | Source | URL |
+-----------+--------------------------+----------------------+
| NENA | National Emergency | http://www.nena.org |
| | Number Association | |
| EENA | European Emergency | http://www.eena.org |
| | Number Association | |
| domain | (The ID is a fully-qualified domain name) | (not applicable) |
+-----------+--------------------------+----------------------+

Second, a new subregistry will be created in the "Emergency Call Additional Data" registry called the Service Environment subregistry. This registry will be maintained via Expert Review as defined in RFC 5226.

These are the initial registrations:

+-----------+--------------------------+
| Token | Description |
+-----------+--------------------------+
| Business | Business service |
| Residence | Residential service |
| unknown | Type of service unknown |
| (e.g., anonymous pre- |
| | paid service) |
+-----------+--------------------------+

Third, a new subregistry will be created in the "Emergency Call Additional Data" registry called the Service Type subregistry. This registry will be maintained via Expert Review as defined in RFC 5226.

These are the initial registrations:

+--------------+----------------------------------------+
| Name | Description |
+--------------+----------------------------------------+
| wireless | Wireless Telephone Service: Includes |
| | CDMA, GSM, Wi-Fi, WiMAX, LTE (but |
| | not satellite) |
| coin | Fixed public pay/coin telephones: Any |
| | coin or credit card operated device |
| one-way | One way outbound service |
| prison | Inmate call/service |
| temp | Soft dial tone/quick service/warm |
| | disconnect/suspended |
| MLTS-hosted | Hosted multi-line telephone system |
| | such as Centrex |
| MLTS-local | Local multi-line telephone system, |
| | includes all PBX, key systems, |
| | Shared Tenant Service |
| sensor- | These are devices that generate DATA |
| unattended | ONLY. This is a one-way information |
| | transmit without interactive media |
| sensor- | Devices that are supported by a |
| attended | monitoring service provider or that |
| | are capable of supporting interactive|
| | media |
| POTS | Wireline: Plain Old Telephone Service |
| VOIP | An over-the-top service that provides |
| | communication over arbitrary Internet|
| | access (fixed, nomadic, mobile) |
| remote | Off-premise extension |
| relay | A service where a human third-party |
| | agent provides additional assistance |
| | This includes sign language relay/ |
| | interpretation, telematics services |
| | that provide a human on the call, |
| | and similar services. |
+--------------+----------------------------------------+

Fourth, a new subregistry will be created in the "Emergency Call Additional Data" registry called the Service Mobility subregistry. This registry will be maintained via Expert Review as defined in RFC 5226.

These are the initial registrations:

+-----------+----------------------------+
| Token | Description |
+-----------+----------------------------+
| Mobile | The device is able to move |
| | at any time |
| Fixed | The device is not expected |
| | to move unless the |
| | service is relocated |
| Nomadic | The device is not expected |
| | to change its point of |
| | attachment while on a |
| | call |
| Unknown | No information is known |
| | about the service |
| | mobility environment for |
| | the device |
+-----------+----------------------------+

Fifth, a new subregistry will be created in the "Emergency Call Additional Data" registry called the Service Provider Type subregistry. This registry will be maintained via Expert Review as defined in RFC 5226.

These are the initial registrations:

+------------------------------+------------------------------------+
| Token | Description |
+------------------------------+------------------------------------+
|Client | Originating client/device |
|Access Network Provider | Access network service provider |
|Telecom Provider | Telecom service provider (including|
| | over-the-top VoIP services) |
|Telematics Provider | A sensor-based service provider, |
| | especially vehicle-based |
|Language Translation Provider | A spoken language translation |
| | service |
|Emergency Service Provider | An emergency service provider |
| | conveying information to another|
| | emergency service provider. |
|Emergency Modality Translation| An emergency-call-specific |
| | modality translation service |
| | e.g., for sign language |
|Relay Provider | A interpretation service, e.g., |
| | video relay for sign language |
| | interpreting |
|Other | Any other type of service provider |
+------------------------------+------------------------------------+

Sixth, a new subregistry will be created in the "Emergency Call Additional Data" registry called the Device Classification subregistry. This registry will be maintained via Expert Review as defined in RFC 5226.

These are the initial registrations:

+---------------+----------------------------------------+
| Token | Description |
+---------------+----------------------------------------+
|cordless | Cordless handset |
|fixed | Fixed phone |
|satellite | Satellite phone |
|sensor-fixed | Fixed (non mobile) sensor/alarm device |
|desktop | Soft client on desktop PC |
|laptop | Soft client on laptop type device |
|tablet | Soft client on tablet type device |
|alarm-monitored| Alarm system |
|sensor-mobile | Mobile sensor device |
|aircraft | Aircraft telematics device |
|automobile | Automobile/cycle/off-road telematics |
|truck | Truck/construction telematics |
|farm | Farm equipment telematics |
|marine | Marine telematics |
|personal | Personal telematics device |
|feature-phone | Feature- (not smart-) cellular phone |
|smart-phone | Smart-phone cellular phone (native) |
|smart-phone-app| Soft client app on smart-phone |
|unknown-device | Soft client on unknown device type |
|game | Gaming console |
|text-only | Other text device |
|NA | Not Available |
+---------------+----------------------------------------+

Seventh, a new subregistry will be created in the "Emergency Call Additional Data" registry called the Device ID Type subregistry. This registry will be maintained via Expert Review as defined in RFC 5226.

These are the initial registrations:

+--------+------------------------------------------+
| Token | Description |
+--------+------------------------------------------+
| MEID | Mobile Equipment Identifier (CDMA) |
| ESN | Electronic Serial Number (GSM) |
| MAC | Media Access Control Address (IEEE) |
| WiMAX | Device Certificate Unique ID |
| IMEI | International Mobile Equipment ID (GSM) |
| IMSI | International Mobile Subscriber ID (GSM) |
| UDI | Unique Device Identifier |
| RFID | Radio Frequency Identification |
| SN | Manufacturer Serial Number |
+--------+------------------------------------------+

Eighth, a new subregistry will be created in the "Emergency Call Additional Data" registry called the Device/Service Data Type subregistry. This registry will be maintained via Expert Review as defined in RFC 5226.

These are the initial registrations:

+----------+----------------------------+----------------------------+
| Token | Description | Specification |
+----------+----------------------------+----------------------------+
| IEEE1512 | Common Incident Management |IEEE 1512-2006 |
| | Message Set (USDoT model |https://standards.ieee.org/ |
| | for traffic incidents) |findstds/standard/1512-2006.html|
+----------+----------------------------+----------------------------+

Ninth, this document requests the creation of a registry called 'Emergency Call Data Types' in the 'purpose' registry established by RFC 3261 [RFC3261].

    +----------------+--------------+------------+
      | Token          |  Data About  | Reference  |
      +----------------+--------------+------------+
      | ProviderInfo  |  The Call  | [This RFC] |
      | ServiceInfo    |  The Call  | [This RFC] |
      | DeviceInfo    |  The Call  | [This RFC] |
      | SubscriberInfo |  The Call  | [This RFC] |
      | Comment        |  The Call  | [This RFC] |
      +----------------+--------------+------------+

QUESTION: As the "purpose" registry was never created, should this registry be created at the new URL or in http://www.iana.org/assignments/sip-parameters?

Tenth, this document defines the 'EmergencyCallData' value for the 'purpose' parameter of the Call-Info header field.

QUESTION: In the absence of the "purpose" registry, should IANA add another reference to the Call-Info header/purpose parameter registration in the Header Field Parameters and Parameter Values registry at http://www.iana.org/assignments/sip-parameters?

This possible action -- adding another reference to the "purpose" registration itself, in the absence of a "purpose" sub-registry -- is the action requested explicitly by Section 3 of RFC 6993 and Section 5.1 of RFC 7082.

Eleventh, in the XML Namespaces for 'provided-by' elements for use with PIDF-LO objects subregistry of the US National Emergency Number Administration (NENA) Provided-By Schema located at:

http://www.iana.org/assignments/xml-ns-provided-by/

a new namespace will be registered as follows:

namespace URI: urn:ietf:params:xml:ns:EmergencyCallData
Application File: [ TBD-at-Registration ]
Registrant Contact: IESG
Optional Reference:

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we have initiated the Expert Review in a separate ticket. Expert review will need to be completed before this registration can be completed.

Twelfth, in the application media type subregistry of the Media Types registry located at:

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

Five new media types will be registered as follows:

application/EmergencyCallData.ProviderInfo+xml
application/EmergencyCallData.ServiceInfo+xml
application/EmergencyCallData.DeviceInfo+xml
application/EmergencyCallData.SubscriberInfo+xml
application/EmergencyCallData.Comment+xml

Thirteenth, in the ns subregistry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/

six new namespaces are to be registered as follows:

ID: EmergencyCallData
URI: urn:ietf:params:xml:ns:EmergencyCallData
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo
URI: EmergencyCallData:ProviderInfo
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: EmergencyCallData:ServiceInfo
URI: urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: EmergencyCallData:DeviceInfo
URI: urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: EmergencyCallData:SubscriberInfo
URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: EmergencyCallData:Comment
URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we have initiated the required Expert Review via a separate request. Expert review will need to be completed before these registrations can be completed. We understand that the designated experts for this registry may have questions about these registrations.

Fourteenth, in the schema subregistry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/

five new namespaces are to be registered as follows:

ID: emergencycalldata:ProviderInfo
URI: urn:ietf:params:xml:schema:emergencycalldata:ProviderInfo
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: emergencycalldata:ServiceInfo
URI: urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: emergencycalldata:DeviceInfo
URI: urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: emergencycalldata:SubscriberInfo
URI: urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: emergencycalldata:comment
URI: urn:ietf:params:xml:schema:emergencycalldata:comment
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we have initiated the required Expert Review via a separate request. Expert review will need to be completed before these registrations can be completed. We understand that the designated experts for this registry may have questions about these registrations.

Fifteenth, in the vCard Parameter Values subregistry of the vCard Elements registry located at:

http://www.iana.org/assignments/vcard-elements/

a new value will be registered as follows:

Property: MAIN
Parameter: TYPE
Value: main
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we have initiated the Expert Review in a separate ticket. Expert review will need to be completed before these registrations can be made.

IANA understands that only these 15 actions are required.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

thanks,

Amanda Baber
IANA Senior Specialist
ICANN

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ecrit-additional-data-33, and its reviewer has the following questions and comments:

IANA understands that, upon approval, this document makes a significant request for actions by IANA. This note summarizes IANA's understanding of the requests being made in the document. A detailed review will be submitted by Wednesday, 26 August 2015.

Please note that IANA has question about the requests in sections 10.1.9 and 10.2. Please see below.

This document requests the creation of a new registry on the IANA matrix called the "Emergency Call Additional Data" registry. In this new registry, eight new subregistries are to be created and IANA understands these to be:

'Additional Call Data Provider ID Series'
'Additional Call Service Environment'
'Additional Call Service Type'
'Additional Call Service Mobility'
'Service Provider Type'
'Device Classification'
'Additional Call Data Device ID Type'
'Device/Service Data Type Registry'

This document requests the creation of a registry called 'Emergency Call Data Types' in the 'purpose' registry established by RFC 3261 [RFC3261].

QUESTION: Where is the 'purpose' registry?

This document defines the 'EmergencyCallData' value for the 'purpose' parameter of the Call-Info header field.

QUESTION: Where is the registry for this parameter? Would the appropriate action actually be to add another reference to the Call-Info header/purpose parameter registration in the Header Field Parameters and Parameter Values registry at http://www.iana.org/assignments/sip-parameters? See similar actions in Section 3 of RFC 6993 and Section 5.1 of RFC 7082.

This document registers a new URN Sub-Namespace in the registry established by RFC 4119.

This document makes five new MIME registrations:

application/EmergencyCallData.ProviderInfo+xml
application/EmergencyCallData.ServiceInfo+xml
application/EmergencyCallData.DeviceInfo+xml
application/EmergencyCallData.SubscriberInfo+xml
application/EmergencyCallData.Comment+xml

This document also registers six new namespaces in the URN sub-namespace, as follows:

urn:ietf:params:xml:ns:EmergencyCallData
urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo
urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo
urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo
urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo
urn:ietf:params:xml:ns:EmergencyCallData:Comment

This document also registers five schemas, as follows:

urn:ietf:params:xml:schema:emergencycalldata:ProviderInfo
urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo
urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo
urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo
urn:ietf:params:xml:schema:emergencycalldata:comment

NOTE: IANA will ask the designated experts to approve the ns and schema registrations.

This document registers a new value in the vCARD Parameter Values registry as defined by [RFC6350].

NOTE: IANA will ask the designated expert to approve this registration.

IANA understands that this summary is an accurate reflection of all the IANA actions required upon approval of this document. IANA intends to provide a detailed review of the IANA actions requested by this document on Wednesday, 26 August 2015.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Additional Data Related to an Emergency Call) to Proposed Standard


The IESG has received a request from the Emergency Context Resolution
with Internet Technologies WG (ecrit) to consider the following document:
- 'Additional Data Related to an Emergency Call'
  as Proposed Standard

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 2015-08-24. 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


  When an emergency call is sent to a Public Safety Answering Point
  (PSAP), the originating device, the access network provider to which
  the device is connected, and all service providers in the path of the
  call have information about the call, the caller or the location
  which is helpful for the PSAP to have in handling the emergency.
  This document describes data structures and mechanisms to convey such
  data to the PSAP.  The intent is that every emergency call carry the
  information described here using the mechanisms described here.

  The mechanisms permit the data to be conveyed by reference (as an
  external resource) or by value (within the body of a SIP message or a
  location object).  This follows the tradition of prior emergency
  services standardization work where data can be conveyed by value
  within the call signaling (i.e., in the body of the SIP message) or
  by reference.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ballot/


No IPR declarations have been submitted directly on this I-D.

> Document Shepherd Writeup per RFC 4858 template, (dated 24 February 2012), for the following work group draft:
>
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
>
>
> (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 “Proposed Standard”, since the draft provides guidelines.
>
>
> (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]
> When an emergency call is sent to a Public Safety Answering Point
> (PSAP), the device that sends it, as well as any application service
> provider in the path of the call, or access network provider through
> which the call originated may have information about the call, the
> caller or the location which the PSAP may be able to use.
>
> This document describes data structures and a mechanism to convey such
> data to the PSAP.  The mechanism uses a Uniform Resource Identifier
> (URI), which may point to either an external resource or an object in
> the body of the SIP message.  The mechanism thus allows the data to
> be passed by reference (when the URI points to an external resource)
> or by value (when it points into the body of the message).  This
> follows the tradition of prior emergency services standardization
> work where data can be conveyed by value within the call signaling
> (i.e., in body of the SIP message) and also by reference.
>
>
> 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 a good amount of work group participation in contributing, discussing, and revising the details that make up 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 working group 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 per this document.  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 Marc Linsner.
> Area Director is Alissa Cooper.
>
>
> (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.
>
> I have confirmation from each author that all IPR has disclosed.
>
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>
> None that I am aware of.
>
>
> (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 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 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.
>
>  Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
>
>
> (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, and therefore N/A.
>
>
> (15) Are there downward normative 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.

> Document Shepherd Writeup per RFC 4858 template, (dated 24 February 2012), for the following work group draft:
>
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
>
>
> (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 “Proposed Standard”, since the draft provides guidelines.  The title page lists it currently as “Unknown”.
>
>
> (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]
> When an emergency call is sent to a Public Safety Answering Point
> (PSAP), the device that sends it, as well as any application service
> provider in the path of the call, or access network provider through
> which the call originated may have information about the call, the
> caller or the location which the PSAP may be able to use.
>
> This document describes data structures and a mechanism to convey such
> data to the PSAP.  The mechanism uses a Uniform Resource Identifier
> (URI), which may point to either an external resource or an object in
> the body of the SIP message.  The mechanism thus allows the data to
> be passed by reference (when the URI points to an external resource)
> or by value (when it points into the body of the message).  This
> follows the tradition of prior emergency services standardization
> work where data can be conveyed by value within the call signaling
> (i.e., in body of the SIP message) and also by reference.
>
>
> 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 a good amount of work group participation in contributing, discussing, and revising the details that make up 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 working group 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 per this document.  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 Marc Linsner.
> Area Director is Alissa Cooper.
>
>
> (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.
>
> I have confirmation from each author that all IPR has disclosed.
>
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>
> None that I am aware of.
>
>
> (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 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 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.
>
>  Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
>
>
> (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, and therefore N/A.
>
>
> (15) Are there downward normative 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.

Notification list changed to draft-ietf-ecrit-additional-data.ad@ietf.org, draft-ietf-ecrit-additional-data@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit@ietf.org, "Marc Linsner" <mlinsner@cisco.com> from draft-ietf-ecrit-additional-data.ad@ietf.org, draft-ietf-ecrit-additional-data@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit@ietf.org