URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
draft-ietf-salud-alert-info-urns-14

[Ballot comment]
Thanks for addressing all of my DISCUSS points.

--------------

Section 5:
"REQ-4: has been deleted.  To avoid confusion, the number will not be
  reused."

This reads oddly. If you want to keep this in, something like this would be better:
"REQ-4: This requirement appeared in earlier versions of the document, but has been deleted. To avoid confusion, the number will not be reused."

On the other hand, the REQs are never referenced again in the document as far as I can tell, so is it really that hard to re-number them? Or is REQ-4 left in because the requirements are referenced in other documents?

REQ-10:
s/uncomon set/uncommon set/

REQ-16:
s/not subject of/not the subject of/

REQ-18:
s/not subject of/not the subject of/

Section 6.2.1:
"Because the call-waiting information may be subject to the
  callee's privacy concerns, the exposure of this information shall be
  done only if explicitly required by the callee."

Agree with Barry's comment here. Seems like if any of the parties would be "requiring" this, it would be the caller, not the callee. But in any event it should be up to the callee to decide whether to expose this info.

Section 7:
s/ and [RFC3406]/ and [RFC3406]./

Section 8.2:
s/no-operation"alert" URN/no-operation "alert" URN/

Section 8.2.2:
The inclusion of "friend" and "family" made me wonder why an indication of "work" or "professional" (as opposed to friend/family) was not included. Work colleagues may be internal or external, so this would be a separate classification from all of the ones already listed. I would guess usage of this would be desirable if "friend" and "family" are as well.

Section 10.1:
s/an new /a new /

Section 10.2:
"Within a URN, all  components that follow a  but are before any following s are additional
  private extensions whose meaning is defined by the organization
  defining the ."

The phrase "the " is possibly ambiguous. I think what is meant at the end of this sentence is "the organization defining the  immediately prior in the hierarchy."

"(In either
  case, the organization SHOULD use the existing URN for its purposes.)"
 
This seems a bit superfluous. It's like saying organizations should use the URNs they mint, but there are cases where they shouldn't. Isn't that what will happen anyway regardless of what this draft says?

Section 14:
s/A A SIP proxy/A SIP proxy/

[Ballot comment]
Thanks for addressing my discuss point in 8.2.2 with a clarifying sentence as well as overhauling the security considerations section to address the SecDir review, Stephen, & Alissa's comments.  The updated Security considerations section works for me.

[Ballot comment]
Thanks very much for addressing all my concerns, including those that came up in the conversation with Alissa.  I'm happy with the result... and I hope the working group is as well.

[Ballot comment]
The Gen-ART review from Alexey and comments from Ben indicated that the unclear MUST requirement text needs a change. I can see that the authors are working on that. I think the text really needs to change, but since you have already taken on the task to do the changes, I am not raising a Discuss and are expecting Richard and others to make sure that the change happens.

[Ballot comment]
Ah, it's so nice to be late and just agree with Alissa and Barry's DISCUSS points.

Section 5 should be removed or moved to an appendix.

[Ballot discuss]
Hopefully, this is an easy one to clear up.  I just want to make sure we address possible security and privacy concerns. 

I read through the draft and am unclear on how a source is determined to be a family member or friend (Section 9.2.2).  If this is determined by the source, how does a receiver know it is accurate?  Are there data sensitivity or privacy issues that need to be considered passing or storing this sort of information?  It seems a little creepy to me (but maybe that's just me), I'd rather a number or name pop up without the phone system knowing who everyone in my life is to me.  Is this determined by the source as is stated or in a local comparison by the receiver as is done now with contact lists, etc.?

[Ballot comment]
In the abstract: "The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted."  Rendering of what?  The abstract shouldn't assume that the reader knows.

In 8.2.2, it seems weird that the recipient would accept the "family" or "friend" indication from the sender.  The security considerations address the larger point of trusting the sender generally, but I think this is different because it can only make sense when the sender has knowledge about the recipient's relationships.  It seems like the wrong way to do this, and I am not convinced that it belongs here.

I'm not raising it as a DISCUSS because it's not an interop issue and probably won't break the internet, but it seems weird and seems to have potential for abuse.  What was the motivation for adding this?  If it's to codify existing practice, it might be worth putting text in the security considerations addressing these specific indicators and saying that they are a bad idea, and are not recommended, but are included to address current practice.

Otherwise (and modulo some other IESG review comments) the document is well written, easy to follow, and looks good.  Thanks for doing it!

[Ballot comment]

- I agree with Alissa's discuss point on section 16 and with
the secdir review [1] on that topic.

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

- The private name + date thing seems over-complex really.

- 9.2.6: you mean you want to add each country code to the
IANA registry? Seems like a bad plan if so.

[Ballot discuss]
Section 10.3:

I think it's unnecessary and out of the IETF's scope to be defining new intellectual property rights in URNs. I can understand the desire to provide some warning to organizations to say "don't squat on someone else's  name," but ultimately if a registry is not being defined, there is nothing the IETF can do to require organizations to follow that guidance. If it's that important, then the proper way to handle this would be with a registry.

I think it would be reasonable to retain the suggestion that, at the time when a  is being defined, it should be defined by the registered owner of the corresponding  (second para of 10.3), but drop the rest (third para of 10.3). When domain name ownership gets transferred, the transferor and the transferee will have to work out who maintains the definition of the 's URNs.

(As an aside, the date stuff seems superfluous as well. I have a hard time believing it will get used, but I'm assuming there is some reason for it to be there in the first place? I see that there is some precedent for the provider+date structure in RFC 4198.

Section 16:
Even with authorization, the caller or callee may want to protect the confidentiality of these alerts (along with other headers). I agree with the SECDIR reviewer's suggestion about mentioning the use of TLS here, with appropriate caveats about difficulty of deployment.

[Ballot comment]
Section 5:
"REQ-4: has been deleted.  To avoid confusion, the number will not be
  reused."

This reads oddly. If you want to keep this in, something like this would be better:
"REQ-4: This requirement appeared in earlier versions of the document, but has been deleted. To avoid confusion, the number will not be reused."

On the other hand, the REQs are never referenced again in the document as far as I can tell, so is it really that hard to re-number them? Or is REQ-4 left in because the requirements are referenced in other documents?

REQ-10:
s/uncomon set/uncommon set/

REQ-16:
s/not subject of/not the subject of/

REQ-18:
s/not subject of/not the subject of/

Section 6.2.1:
"Because the call-waiting information may be subject to the
  callee's privacy concerns, the exposure of this information shall be
  done only if explicitly required by the callee."

Agree with Barry's comment here. Seems like if any of the parties would be "requiring" this, it would be the caller, not the callee. But in any event it should be up to the callee to decide whether to expose this info.

Section 7:
s/ and [RFC3406]/ and [RFC3406]./

Section 8.2:
s/no-operation"alert" URN/no-operation "alert" URN/

Section 8.2.2:
The inclusion of "friend" and "family" made me wonder why an indication of "work" or "professional" (as opposed to friend/family) was not included. Work colleagues may be internal or external, so this would be a separate classification from all of the ones already listed. I would guess usage of this would be desirable if "friend" and "family" are as well.

Section 10.1:
s/an new /a new /

Section 10.2:
"Within a URN, all  components that follow a  but are before any following s are additional
  private extensions whose meaning is defined by the organization
  defining the ."

The phrase "the " is possibly ambiguous. I think what is meant at the end of this sentence is "the organization defining the  immediately prior in the hierarchy."

"(In either
  case, the organization SHOULD use the existing URN for its purposes.)"
 
This seems a bit superfluous. It's like saying organizations should use the URNs they mint, but there are cases where they shouldn't. Isn't that what will happen anyway regardless of what this draft says?

Section 14:
s/A A SIP proxy/A SIP proxy/

[Ballot discuss]
-- Sections 9.1, 9.2, 10.1 --
I worry that we're painting ourselves into an undesirable corner here by using Standards Action for the registration policies.  Is it truly inappropriate to use Specification Required or Expert Review, and to let a designated expert that the IESG appoints stand in for (1) overall IETF review and (2) the demand that the registration be done in a Standards Track RFC?

We have too many cases when we've later regretted using Standards Action or IETF Review (the registration of a URN NID being one of them; we're in the pocess of changing that policy in the urnbis working group).  And especially if you want other standards outside the IETF to use these, requiring them to get an IETF Standards Track RFC or to use private names doesn't seem reasonable.

Can you please explain the reason for holding to Standards Action, and the harm that would be caused by using some form of expert review instead?

[Ballot comment]
This is a good, thoroughly thought-out document.  I can't tell you how many times I typed a quick comment note as I was reading, only to find it addressed a paragraph or two later.

-- Section 6.2.1 --

  Because the call-waiting information may be subject to the
  callee's privacy concerns, the exposure of this information shall be
  done only if explicitly required by the callee.

I think you mean explicitly "permitted" by the callee, no?

-- Section 6.2.2 --
Is this not also subject to privacy concerns in the same way that a call-waiting signal is?  If someone calls my home phone and knows that the call is being forwarded, she can assume I'm not home and go burglarize my house.

-- Section 6.3 --
Just a note on this, which you can take or leave as you please: I find that when I'm not familiar with the tones that a country uses, I may actually be confused by hearing them: perhaps a "busy signal" ("engaged tone") from one country sounds to me like a "ringing" tone, and I wait on the line for a response... or the other way 'round, or something like that.  That sort of thing has happened to me, so it's not just hypothetical.  It's not clear that it's a good idea to give callers the tones that are meaningful to the callee... and might be better to use tones that mean something to the caller.

I'm sure you've talked about this, so all I'm wondering here is whether it's worth saying a few words in this section.  What's here makes it sound as though it's always better to provide the caller with the callee's tones.  What it says is decidedly *not* true for me, as one example.

-- Section 7 --
For the contact information, you give , and attribute it to the "RAI Area Director".  Is there actually such an email address?  Is it a general RAI area mailing list?  Or do you mean  ?

-- Section 10.2 --

  Once an organization obtains the right to use a particular
  for constructing s, it will retain that right forever,
  unless it transfers that right to another organization.

How does an organization obtain that right, and from whom?  How does it transfer the right?  I guess that's meant to be specified in Section 10.3, so at the very least a forward reference is in order.  But perhaps it's better still to delete this paragraph entirely, and roll the essence of it into Section 10.3, where the rest of that thought lives.

-- Section 10.3 --
Should we be specifying intellectual property rights in our standards, when those rights don't apply to the IETF?  We should probably at least have Jorge look at this section and advise us.

And do you really expect domain owners to research whether they're the first to hold their domain names, in order to know whether they need to incorporate a date or not?  I suspect that dates will be used very fluffily, if at all.

-- Section 10.4.2 --

  However, before defining such a URN, the organization should verify
  that the set of calls to which the URN applies is not a subset of the
  set of calls for some existing URN.  If it is a subset, the extension
  URN should be a subdivision of the existing URN.

I think I know what this means, but I had to read it three times before I thought I was sure.  Maybe a bit of rewording or more explanation would be useful.

-- Section 11.1 --

Bullet (b) is something that has been mentioned before, but in the earlier contexts I thought it was optional.  Bullet (b) is worded so that is not optional ("the UA repeatedly removes the final  of the URN until") -- describing it as what is done, as opposed to what can (or MAY) be done, makes it an integral part of the protocol.

Is it meant to be what is always done, or is it meant to be optional?

      When selecting from the set of equally
      effective signals, no signal should be chosen if a less-specific
      signal is also in the set.

I find the negative plus the "if less is" to be a little confusing.  I wonder whether non-native speakers, or less-than-careful readers might be prone to misunderstanding it.  Does this work for you?:

NEW
      When selecting from the set of equally
      effective signals, the least specific signal in the set should
      be chosen.
END

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-salud-alert-info-urns-12.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a few questions for one of the requested IANA actions in this
draft document.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Formal URN Namespaces subregistry of the Uniform Resource Names (URN) Namespaces registry located at:

http://www.iana.org/assignments/urn-namespaces/

a new URN will be registered as follows:

URN Namespace: alert
Reference: [ RFC-to-be ]

Second, a new registry called the Alert URN Identifiers registry is to be created. New URNs in the Alert URN Identifiers Registry are created through Standards Action as defined by RFC 5226.

QUESTIONs:
Should this new registry a sub-registry of the registry
'Service URN Labels' located at
http://www.iana.org/assignments/urn-serviceid-labels?  Or is this new
registry 'Alert URN Identifiers' a stand-alone with a brand new URL? 

Then, if the latter, what should be the name of the master "Parameter"
registry?  Is Uniform Resource Names (URN)?  See iana.org/protocols for
a list of main registry pages and the registries they include.

IANA understands that the initial registrations in this new registry are to be collected from section 9.2.1 through 9.2.6 of the current document. IANA understands that the initial registry will look like this:

/ Reference Description

--------------------------------------------------------------------------
service [ RFC-to-be ] Specific telephony
service used in this
call
service:normal [ RFC-to-be ] Normal ring/ringback
rendering (default value)
service:call-waiting [ RFC-to-be ] Call waiting was
initiated at the other side
of the call
service:forward [ RFC-to-be ] Call has been forwarded
service:recall:callback [ RFC-to-be ] Recall due to callback
service:recall:hold [ RFC-to-be ] Recall due to call hold
service:recall:transfer [ RFC-to-be ] Recall due to transfer
source [ RFC-to-be ] Classification
of the other party
to the call
source:unclassified [ RFC-to-be ] Unclassified ring/ringback
rendering (default value)
source:internal [ RFC-to-be ] User at the other side of
the call is internal to the
enterprise or PBX system
source:external [ RFC-to-be ] User at the other side of
the call is external to the
enterprise or PBX system
source:friend [ RFC-to-be ] User at the other side of
the call is a friend
source:family [ RFC-to-be ] User at the other side of
the call is a family member
priority [ RFC-to-be ] Priority of the
call
priority:normal [ RFC-to-be ] Normal ring/ringback
rendering (default value)
priority:low [ RFC-to-be ] Low priority call.
priority:high [ RFC-to-be ] High priority call
duration [ RFC-to-be ] Duration of alerting signal
alerting signal
duration:normal [ RFC-to-be ] Normal ring/ringback
rendering (default value)
duration:short [ RFC-to-be ] Shorter than normal
duration:long [ RFC-to-be ] Longer than normal
delay [ RFC-to-be ] Delay of rendering of alerting
of alerting signal
delay:none [ RFC-to-be ] Immediate alerting
(default value)
delay:yes [ RFC-to-be ] Delayed alerting
locale [ RFC-to-be ] Location-specific
alerting signals
locale:default [ RFC-to-be ] Alerting not location
specific
(default value)
locale:country:
[ RFC-to-be ] Alerting according to the
conventions of the specified
country

IANA understands that these two actions are the only ones that need to be completed upon approval of this document.
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:  (URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)) to Proposed Standard


The IESG has received a request from the Sip ALerting for User Devices WG
(salud) to consider the following document:
- 'URNs for the Alert-Info Header Field of the Session Initiation
  Protocol (SIP)'
  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 2014-04-25. 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


  The Session Initiation Protocol (SIP) supports the capability to
  provide a reference to a specific rendering to be used by the UA when
  the user is alerted.  This is done using the Alert-Info header field.
  However, the reference (typically a URL) addresses only a specific
  network resource with specific rendering properties.  There is
  currently no support for standard identifiers for describing the
  semantics of the alerting situation or the characteristics of the
  alerting signal, without being tied to a particular rendering.  To
  overcome these limitations and support new applications, a new family
  of URNs for use in Alert-Info header fields (and situations with
  similar requirements) is defined in this specification.

  This document normatively updates the RFC 3261, which defines the
  Session Initiation Protocol (SIP): It changes the usage of the Alert-
  Info header field defined in the RFC 3261 by additionally allowing
  its use in all provisional responses to INVITE (except the 100
  response).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-salud-alert-info-urns/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-salud-alert-info-urns/ballot/


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

Document:  URNs for the Alert-Info Header Field of the Session
Initiation Protocol (SIP)
draft-ietf-salud-alert-info-urns-12

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

Proposed Standard.

The relevant parts of the definition of "Proposed Standard", given in
RFC 2026 and reiterated in RFC 6410, are:

  A Proposed Standard specification is generally stable, has resolved
  known design choices, is believed to be well-understood, has received
  significant community review, and appears to enjoy enough community
  interest to be considered valuable.

  Usually, neither implementation nor operational experience is
  required for the designation of a specification as a Proposed
  Standard.  However, such experience is highly desirable, and will
  usually represent a strong argument in favor of a Proposed Standard
  designation.

  A Proposed Standard should have no known technical omissions with
  respect to the requirements placed upon it.

The working group believes that all known design issues have been
resolved, and that the design satisfies all of the stated requirements
(listed in section 5), as well as the standards for SIP and for URN
namespaces.

This document also updates RFC 3261 by permitting the Alert-Info
header to appear in all non-100 provisional SIP responses.

Deutsche Telekom has indicated that they intend to implement this document.

One particular URN  that is defined in this
document is referenced in draft-ietf-bliss-shared-appearances-15,
which is in the RFC Editor queue (and is itself Standards Track).

The "Standards Track" status is indicated on the title page header.

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

The Session Initiation Protocol (SIP) supports the capability to
provide a reference to a specific rendering to be used by the UA when
the user is alerted.  This is done using the Alert-Info header field.
However, providing a reference (typically a URL) addresses only a
specific network resource with specific rendering properties.  This
document defines a new namespace of URNs for use in Alert-Info header
fields.  The URNs are defined to describe characteristics of the
incoming call, characteristics of how the call is being handled at the
callee, and rendering characteristics of the desired signal.  The URNs
can be combined to provide complex descriptions of the intended
signal.  Provisions are made for private extensions that can describe
additional signal characteristics and additional subcategorization of
standardized characteristics.  Detailed resolution rules are provided
to ensure that a renderer provides the best representation that it can
of the signaler's intention.

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 is solid consensus in the SALUD WG of the value of this work and
the usefulness of this document.  A large set of requirements has been
identified to ensure that the proposed URNs can be used successfully
in converting existing telephone switches to operate using SIP.

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?

Deutsche Telekom has indicated that they intend to implement this document.

An important review of the proposed URN namespace was done by Alfred
Hoenes, which identified a number of deficiencies in the original
proposal (which have been eliminated).  After revision, the URN
namespace definition was presented on the urn-nid mailing list, and no
objections were raised.

Many reviews have been done by the authors, and a final review by the
Document Shepherd, which convince the WG that there are no substantive
issues remaining.

Personnel:

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

The Document Shepherd is Christer Holmberg.

The Responsible Area Director is Richard Barnes.

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

The Document Shepherd has reviewed the document. The document is well
structured, and the defined extensions are clearly explained. The document
also contains a requirements section, which helps readers to understand
the background and justification to the chosen technical solution.


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

The Document Shepherd is satisfied with the review.


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

As this document defines a new URN namespace, that namespace
definition must be reviewed.  Early in the process, Alfred Hoenes
provided invaluable feedback that allowed a number of important issues
to be corrected.  The current version of the namespace definition was
presented to the urn-nid mailing list, and no objections were made.

Internationalization considerations are listed in section 15.  Since
these URNs are not directly visible to users, internationalization
requirements are relatively modest.

The most important consideration is that a part of the
private-extension syntax includes representation of the domain name of
the private party defining the extension, so the private-extension
syntax must allow internationalized domain names.  This is provided
straightforwardly by allowing A-labels (per RFC 5890) (that is, the
"xn--..." form output by Punycode) to appear as a "domain name" part
of a URN.  Since this mechanism refers to the standardized handling of
internationalized domain names, no special review was given to it.

In addition, the URN system provides a way for a user agent to specify
that a ring tone or ringback tone be used that is customary in a
specific country.

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

The Document Shepherd has no concerns regarding the technical content of
the document. The Shepherd assumes that potential minor language nits
will be taken care of by the RFC Editor.


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

Yes, all five authors have confirmed compliance with BCPs 78 and 79.
The confirmations are archived on the Salud WG mailing list.

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

As of 23 Feb 2014, none have been filed referencing this document.

(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 solid consensus in the SALUD WG of the value of this work and
this specific document.

(10) Has anyone threatened an appeal or otherwise indicated
extreme discontent? If so, please summarise the areas of
conflict in separate email messages to the Responsible Area
Director. (It should be in a separate email because this
questionnaire is publicly available.)

The chairs and the Document Shepherd are not aware of such cases.

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

The significant warnings found by the ID-Nits tool 2.13.00  are:

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC3261, but the
    abstract doesn't seem to directly say this.  It does mention RFC3261
    though, so this could be OK.

(This warning is incorrect, as the Abstract says "This document
normatively updates RFC 3261 ...".)

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC3261, updated by this document, for
    RFC5378 checks: 2002-02-21)

  -- The document seems to contain a disclaimer for pre-RFC5378 work, and may
    have content which was first submitted before 10 November 2008.  The
    disclaimer is necessary when there are original authors that you have
    been unable to contact, or if some do not wish to grant the BCP78 rights
    to the IETF Trust.  If you are able to get all authors (current and
    original) to grant those rights, you can and should remove the
    disclaimer; otherwise, the disclaimer is needed and you can ignore this
    comment. (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)

(Section 4.2 of this document largely repeats three sentences of
section 20.4 of RFC 3261.

(We should check with the AD or perhaps the IESG to determine if the
rights for RFC 3261 have been granted.  Give the number of updates to
3261, it is likely that that has been done already, but I know of no
place to verify this.  If these writes have been granted by all
authors, the boilerplate version for the document can be changed from
"pre5378Trust200902" to "trust200902".)

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'RFCXXXX' is mentioned on line 1071, but not
    defined

(All instances of 'RFCXXXX' are to be replaced with the RFC number of
this document.)

(There is an informative reference to
draft-ietf-bliss-shared-appearances.  We expect the RFC Editor to
replace the draft name with its RFC number.
draft-ietf-bliss-shared-appearances is being held in the RFC Editor
queue solely because it references this document;
draft-ietf-bliss-shared-appearances and this document form a cluster.)

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

An important review of the proposed URN namespace was done by Alfred
Hoenes, which identified a number of deficiencies in the original
proposal (which have since been eliminated).  After revision, the URN
namespace definition was presented on the urn-nid mailing list, and no
objections were raised.

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

All normative references are RFCs.

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

No.

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

This document normatively updates RFC 3261.  RFC 3261 is listed on the
title page header, and the update is outlined in the Abstract.  The
specifics of the update are provided in section 4.

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

The Document Shepard has not identified any issues with the IANA
considerations. The document creates a new IANA registry (Alert URN
Identifiers). The rules and guidelines associated with registering
new URN values ( or ) are clearly
described. The initial registry values, described in the document,
follow the rules and guidelines.

(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 of the new IANA registries specified by this document use Expert
Review for future allocations.

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

The only section of the document that could be checked by automation
is the ABNF in section 7.  The ABNF was processed with the IETF ABNF
validator
(http://www.apps.ietf.org/content/chris-newmans-abnf-validator), which
found no problems.