Revision differences

Document history

Date

Rev.

By

Action

2018-12-20

38

(System)

Received changes through RFC Editor sync (changed abstract to 'When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, ...

Received changes through RFC Editor sync (changed abstract to '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 as much of the information described here as possible 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.')

IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup

2015-10-12

37

Cindy Morgan

IESG has approved the document

2015-10-12

37

Cindy Morgan

Closed "Approve" ballot

2015-10-12

37

Cindy Morgan

Ballot approval text was generated

2015-10-12

37

Cindy Morgan

Ballot writeup was changed

2015-10-12

37

Randall Gellens

New version available: draft-ietf-ecrit-additional-data-37.txt

2015-10-04

36

Stephen Farrell

[Ballot comment]

Thanks for handling my discuss points.

-35 handled most of the stuff below just fine but I leftthe comments there. I didn't ...

[Ballot comment]

Thanks for handling my discuss points.

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

- abstract: the "or by reference" point is made twicein the abstract

- intro: floor plans? HVAC status? really? Why notcontact lists? proximity of friends? That (orinferring as much) seems to me to be going too far, ifapplied to all calls. I'd say just saying that thiscould be extended in future by other standards-trackspecifications is enough. (See also discuss points above)

- intro: Wedding anniversary? That's surely notrelevant 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, canyou try explain it to me? (I didn't know it waspossible to tempt an implementation, so the languagethere could be improved for sure:-)

- section 5: good that this is HTTPS only. I thinkprovisioning the PKI for such a thing is easily donethese days and is rightly not optional. It might beuseful to say that TLS here needs to follow BCP195. Iagree with the earlier comment that you should beclear as to when mutually authenticated TLS isrequired. The secdir review [2] also raised similarissues and it'd be good to see responses to that too.(Yes, that review only arrived today so it's entirelyreasonable to not have responded so far.)

- section 8: the sizes of the various additional dataitems here could be characteristic and leak valueinformation regardless of TLS or not-TLS - perhaps adda warning that these may enable relatively simpletraffic analysis. And wouldn't it be nice if someonehad done the analysis of this potential vulnerability?This is btw a real issue - recall that avatar iconimage size was usable to identify 30+% of contacts inone social network even over TLS, but before theprovider canonicalised the avatar image sizes.

- Thanks for section 9. Good job.

2015-10-04

36

Stephen Farrell

[Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss

2015-10-04

36

Randall Gellens

New version available: draft-ietf-ecrit-additional-data-36.txt

2015-09-18

35

Stephen Farrell

[Ballot discuss]

I've two things I'd like to chat about. (Note: I'm not tryinghere to insist on my preferred outcome, but I would like ...

[Ballot discuss]

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

(1) section 3: You say these MAY be used. I'm notsure that's a good option. I think the dataminimisation recommendations argued for in RFC6973 andRFC7258 would argue to add a MUST NOT. For example,saying that these additional data MUST NOT be sent inany non-emergency call without explicit userpermission on a per-call basis or something similar?I have to admit I'm nervous that defining all of thesemay mean that some UA somewhere starts sending some ofthem in other calls without asking. A restrictionalong those lines would also be more in line withwebrtc too perhaps. But maybe this was discussed inthe WG, having considered those privacy issues - wasit? Either way, would adding such a "MUST NOT exceptif..." be a good plan? 4.3.4 is a good example of thekind of thing I'd not want easily emitted in a call.

(2) cleared

2015-09-18

35

Stephen Farrell

[Ballot comment]

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

- abstract: the "or by reference" point is ...

[Ballot comment]

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

- abstract: the "or by reference" point is made twicein the abstract

- intro: floor plans? HVAC status? really? Why notcontact lists? proximity of friends? That (orinferring as much) seems to me to be going too far, ifapplied to all calls. I'd say just saying that thiscould be extended in future by other standards-trackspecifications is enough. (See also discuss points above)

- intro: Wedding anniversary? That's surely notrelevant 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, canyou try explain it to me? (I didn't know it waspossible to tempt an implementation, so the languagethere could be improved for sure:-)

- section 5: good that this is HTTPS only. I thinkprovisioning the PKI for such a thing is easily donethese days and is rightly not optional. It might beuseful to say that TLS here needs to follow BCP195. Iagree with the earlier comment that you should beclear as to when mutually authenticated TLS isrequired. The secdir review [2] also raised similarissues and it'd be good to see responses to that too.(Yes, that review only arrived today so it's entirelyreasonable to not have responded so far.)

- section 8: the sizes of the various additional dataitems here could be characteristic and leak valueinformation regardless of TLS or not-TLS - perhaps adda warning that these may enable relatively simpletraffic analysis. And wouldn't it be nice if someonehad done the analysis of this potential vulnerability?This is btw a real issue - recall that avatar iconimage size was usable to identify 30+% of contacts inone social network even over TLS, but before theprovider canonicalised the avatar image sizes.

- Thanks for section 9. Good job.

2015-09-18

35

Stephen Farrell

Ballot comment and discuss text updated for Stephen Farrell

2015-09-18

35

Barry Leiba

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

A minor thing that the RFC Editor will correct ...

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

2015-09-18

35

Barry Leiba

[Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss

2015-09-16

35

(System)

Sub state has been changed to AD Followup from Revised ID Needed

2015-09-16

35

Randall Gellens

IANA Review state changed to Version Changed - Review Needed from IANA - Not OK

2015-09-16

35

Randall Gellens

New version available: draft-ietf-ecrit-additional-data-35.txt

2015-09-11

34

Gunter Van de Velde

Closed request for Last Call review by OPSDIR with state 'No Response'

2015-09-03

34

Tero Kivinen

Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Magnus Nystrom.

[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, ...

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

2015-09-03

34

Jari Arkko

[Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko

2015-09-03

34

Joel Jaeggli

[Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli

2015-09-02

34

Spencer Dawkins

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

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

2015-09-02

34

Spencer Dawkins

[Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins

2015-09-02

34

Cindy Morgan

Changed consensus to Yes from Unknown

2015-09-02

34

Kathleen Moriarty

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

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

2015-09-02

34

Kathleen Moriarty

[Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty

2015-09-02

34

Brian Haberman

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

- I find text like "Optional for blocks supplied by the originating device, ...

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

2015-09-02

34

Brian Haberman

[Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman

---- In Section 4, you have "tel" and "TYPE", and "property" and "parameter" reversed in the ...

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

2015-09-01

34

Barry Leiba

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

[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 <tel> property is provided, a parameter from the vCard Property Value registry MUST be specified on each <tel>.

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

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

2015-09-01

34

Barry Leiba

[Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba

2015-09-01

34

Deborah Brungard

[Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard

2015-09-01

34

Stephen Farrell

[Ballot discuss]

I've two things I'd like to chat about. (Note: I'm not tryinghere to insist on my preferred outcome, but I would like ...

[Ballot discuss]

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

(1) section 3: You say these MAY be used. I'm notsure that's a good option. I think the dataminimisation recommendations argued for in RFC6973 andRFC7258 would argue to add a MUST NOT. For example,saying that these additional data MUST NOT be sent inany non-emergency call without explicit userpermission on a per-call basis or something similar?I have to admit I'm nervous that defining all of thesemay mean that some UA somewhere starts sending some ofthem in other calls without asking. A restrictionalong those lines would also be more in line withwebrtc too perhaps. But maybe this was discussed inthe WG, having considered those privacy issues - wasit? Either way, would adding such a "MUST NOT exceptif..." be a good plan? 4.3.4 is a good example of thekind of thing I'd not want easily emitted in a call.

(2) I'd like to (perhaps briefly) argue that theregistries here should require more than expertreview. Extensibility in dealing with what willinevitably be highly privacy sensitive data structuresthat are vulnerable to misuse once registered seems toperhaps call for a more stringent registration regime.The document itself also argues (in 4.3.7) that addingnew kinds of data here can be counter productive foremergency call handling, so being more conservative inwhat we add seems unusually correct here. I'd like tosuggest we require standards track for extensions.The following very recent -00 draft [1] makes somerelated arguments (but of course has no standing inthe IETF so is just offered as a way to avoidrepeating some arguments, not as an appeal toauthority.)

- intro: floor plans? HVAC status? really? Why notcontact lists? proximity of friends? That (orinferring as much) seems to me to be going too far, ifapplied to all calls. I'd say just saying that thiscould be extended in future by other standards-trackspecifications is enough. (See also discuss points above)

- intro: Wedding anniversary? That's surely notrelevant 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, canyou try explain it to me? (I didn't know it waspossible to tempt an implementation, so the languagethere could be improved for sure:-)

- section 5: good that this is HTTPS only. I thinkprovisioning the PKI for such a thing is easily donethese days and is rightly not optional. It might beuseful to say that TLS here needs to follow BCP195. Iagree with the earlier comment that you should beclear as to when mutually authenticated TLS isrequired. The secdir review [2] also raised similarissues and it'd be good to see responses to that too.(Yes, that review only arrived today so it's entirelyreasonable to not have responded so far.)

- section 8: the sizes of the various additional dataitems here could be characteristic and leak valueinformation regardless of TLS or not-TLS - perhaps adda warning that these may enable relatively simpletraffic analysis. And wouldn't it be nice if someonehad done the analysis of this potential vulnerability?This is btw a real issue - recall that avatar iconimage size was usable to identify 30+% of contacts inone social network even over TLS, but before theprovider canonicalised the avatar image sizes.

- Thanks for section 9. Good job.

2015-09-01

34

Stephen Farrell

[Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell

2015-09-01

34

Alvaro Retana

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

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

2015-09-01

34

Alvaro Retana

[Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana

2015-09-01

34

Ben Campbell

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

[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 wererequired—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 withSIP. I don't dispute that assumption, but I think it should it's worth aparagraph 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 hostssome VoIP related services for her own use (e.g. a SIP registrar, maybe astun/turn server,etc) Are those in scope? I'm guessing not, since they wouldbe unlikely to be registered with NENA, but it would be worth saying thatexplicitly.

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

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

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

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

-- 4.1.7, Description: "Although multiple <vcard> elements may be containedin a structure only one <vcard> element SHOULD be provided. If more thanone appears, the first SHOULD be used."When might it be reasonable to violate either of these SHOULDs? If thereceiver should only look at the first entry why are multiple entriesallowed at all?

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

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

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

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

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

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

The first paragraph REQUIRES verification of requester credentials, but doesspecify the form of those credentials. Subsequent text talks aboutclient-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 DNSentry of the domain" Can you elaborate on that or cite something?

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

-- section 10: Many of the registry policies require experts to accesswhether an organization might be "legitimate" or "relevant". Are thesereasonable 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 considerbreaking it into simpler sentences.)

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

-- 4.3.1, Description: "It is possible to receive two Additional DataAssociated 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 doingsomething more distinctive than capital letters. Perhaps quotes, or even anabbreviation.

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

-- section 5: It seems awkard to use a numbered list for elements that areclose to a page long each. This forces each to be a single, overlongparagraph. 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 thiscontext. - Sentence starting with: "When the access network provider" This sentence provides context information that would have been useful to have atthe 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 thetables directly. It would be nice to be consistent, one way or the other.

2015-09-01

34

Ben Campbell

Ballot comment text updated for Ben Campbell

2015-08-31

34

Ben Campbell

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

[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 wererequired—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 withSIP. I don't dispute that assumption, but I think it should it's worth aparagraph 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 hostssome VoIP related services for her own use (e.g. a SIP registrar, maybe astun/turn server,etc) Are those in scope? I'm guessing not, since they wouldbe unlikely to be registered with NENA, but it would be worth saying thatexplicitly.

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

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

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

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

-- 4.1.7, Description: "Although multiple <vcard> elements may be containedin a structure only one <vcard> element SHOULD be provided. If more thanone appears, the first SHOULD be used."When might it be reasonable to violate either of these SHOULDs? If thereceiver should only look at the first entry why are multiple entriesallowed at all?

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

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

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

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

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

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

The first paragraph REQUIRES verification of requester credentials, but doesspecify the form of those credentials. Subsequent text talks aboutclient-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 DNSentry of the domain" Can you elaborate on that or cite something?

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

-- section 10: Many of the registry policies require experts to accesswhether an organization might be "legitimate" or "relevant". Are thesereasonable 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 considerbreaking it into simpler sentences.)

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

-- 4.3.1, Description: "It is possible to receive two Additional DataAssociated 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 doingsomething more distinctive than capital letters. Perhaps quotes, or even anabbreviation.

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

-- section 5: It seems awkard to use a numbered list for elements that areclose to a page long each. This forces each to be a single, overlongparagraph. 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 thiscontext. - Sentence starting with: "When the access network provider" This sentence provides context information that would have been useful to have atthe 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 thetables directly. It would be nice to be consistent, one way or the other.

2015-08-31

34

Ben Campbell

[Ballot Position Update] New position, Yes, has been recorded for Ben Campbell

2015-08-27

34

Jean Mahoney

Request for Telechat review by GENART is assigned to Francis Dupont

2015-08-27

34

Jean Mahoney

Request for Telechat review by GENART is assigned to Francis Dupont

2015-08-27

34

(System)

IANA Review state changed to IANA - Not OK from Version Changed - Review Needed

2015-08-27

34

Amanda Baber

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

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

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.

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.

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.

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.

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.

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.

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.

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:

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:

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:

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:

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 BaberIANA Senior SpecialistICANN

2015-08-26

34

Randall Gellens

IANA Review state changed to Version Changed - Review Needed from IANA - Not OK

2015-08-26

34

Randall Gellens

New version available: draft-ietf-ecrit-additional-data-34.txt

2015-08-25

33

Alissa Cooper

Placed on agenda for telechat - 2015-09-03

2015-08-25

33

Alissa Cooper

IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead

2015-08-24

33

(System)

IANA Review state changed to IANA - Not OK from IANA - Review Needed

2015-08-24

33

Amanda Baber

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

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

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.

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 IESG has received a request from the Emergency Context Resolutionwith Internet Technologies WG (ecrit) to consider the following document:- 'Additional Data Related to an Emergency Call' <draft-ietf-ecrit-additional-data-33.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicitsfinal comments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2015-08-24. Exceptionally, comments may besent to iesg@ietf.org instead. In either case, please retain thebeginning 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.

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