Last Call Review of draft-rosen-rph-reg-policy-01
review-rosen-rph-reg-policy-01-genart-lc-carpenter-2013-11-29-00

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-rosen-rph-reg-policy-01.txt
Reviewer: Brian Carpenter
Review Date: 2013-11-29
IETF LC End Date: 2013-12-09
IESG Telechat date:

Summary:  Ready with issues
--------

Comment: This is a sipcore WG draft despite its file name.
--------

Major Issue:
------------

  "Experience
   has suggested that a document that only defines a new namespace with
   its priorities, and does not create new protocol semantics, should
   not be a standards-track document."

I have a couple of problems with this sentence.

1. It reads like a broad statement of IETF policy. Given that we have a normative
document in this area (RFC 5226) and an IAB advisory document about extensions in
general (RFC 6709), I don't think the statement is true in general, regardless of
whether it's true in this particular case.

2. "Experience has suggested..." is a weak justification for a change in policy,
even for these two specific registries. Actually, I can't possibly judge from
the draft whether the change is safe (the considerations for why it might be
safe or dangerous are in RFC 6709).

I would be reassured by an evidence-based justification, along the lines of

"Experience with the N namespaces and M resource-priorities defined since the
publication of RFC 4412, without creating new protocol semantics, has shown
that such definitions do not cause interoperability issues. Therefore documents
that only define such namespaces and priorities do not need to be on the standards
track."

If that isn't true (i.e. there can be interoperability issues) we have a
bigger problem.

Minor issue:
------------

I believe the title, Abstract and Introduction should mention SIP for clarity.

Nit:
----

In the Abstract, s/ ti / to /