Subject: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00

From: Adam Roach <[email-masked]>
Date: Wed, 27 Feb 2013 10:35:30 -0600

[as chair]

During the processing of draft-polk-local-emergency-rph-namespace, the 
IESG, authors, and WG chairs determined that the policy described in 
RFC4412, section 9 for defining a new namespace (Standards-Track RFC) 
was probably selected in error, and that "IETF Review" is likely more 
appropriate. The ECRIT working group has already been informed of this 
situation, and no parties have objected to a change in policy:

http://www.ietf.org/mail-archive/web/ecrit/current/msg08292.html

Since this is a policy change to a core SIP header, our Area Director 
has requested that the document that formally changes the policy be 
processed as a SIPCORE document. The current draft is available here:

http://tools.ietf.org/html/draft-rosen-rph-reg-policy-00

(Aside: ignoring the boilerplate, references, and table of contents, the 
document is about half as long as this email, and should take less time 
to read).

This message starts a call for adoption in parallel with a working group 
last call. Both periods end in just over two weeks, on Friday, March 
15th (the final Friday of the Orlando IETF meeting). Please reply to the 
mailing list indicating support or opposition to such adoption, and with 
any comments on the document contents themselves.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 27 Feb 2013 20:48:15 +0100

I do not have a problem with relaxing the criteria and therefore we will need an I-D to do that, and therefore a milestone to cover that task.

I have the following comments on the document.

1)	Editorial. The document states internally that it updates RFC 4412 and this is correct. However that information also needs to appear in the top left of the document.

2)	The document gives no background material on why IETF review has been chosen, only that it no longer needs to be standards track (Note that I am not convinced "Standards Track" was selected in error). Personally I think "Specification Required" would be entirely appropriate, however if this is used see comment 3) below.

3)	As more relaxed criteria for IANA registration are defined, then material has to be defined to support those reviewing the registration; for a standards track defined protocol, this should be defined in a standards track document. For example RFC 4412 contains no information on when a new namespace is appropriate, as opposed to reuse of an existing namespaces. I have certainly been involved in discussions as to whether the "ETS" namespace is restricted only to usage of "US government telecommunications service" or whether another government body in a different country with identical requirements can reuse the same namespace, or whether they have to define a new namespace, and RFC 4412 does not answer this. So the proposed update currently contains no additional information (to RFC 4412) on:

-	what information needs to be provided for a new namespace or priority level;

-	what criteria need to be met for adopting a new namespace or priority level, versus reusing or modifying an existing one.

4)	Can a new document update an existing namespace with new priority levels or other functionality? I believe this would normally be bad practice for compatibility reasons, but the document does not cover this.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adam Roach
> Sent: 27 February 2013 16:36
> To: 'SIPCORE'
> Cc: [email-masked]
> Subject: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00
> 
> [as chair]
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Feb 2013 15:13:23 -0500

We can fix 1 at AUTH48 if WGLC proceeds.

The document doesn't have to say why a particular management policy was chosen.  It has to be the appropriate policy that the IETF agrees on.  In this case, we think an Informational RFC is adequate to add a new namespace but doesn't define new protocol behavior.  We think IETF Review is appropriate, so that we get review by the rather distributed constituency that cares about this particular piece of stuff.  I don't think Specification Required is adequate -- I want IETF experts to review.  I don't even think Expert Review is adequate, because we do have several different classes of people who care about various aspects of this.

While I somewhat agree that 4412 is light on text defining when a new namespace is appropriate, it isn't the purpose of this document to rewrite that text, but rather to fix a specific problem that holds up other RFCs.  If the policy is left at Standards Track, it still doesn't define when a new namespace is appropriate.  It still doesn't define whether an update to an existing namespace is required.

We could start an effort to do a 4412-bis to address these issues, but I would prefer not to turn this document into that.

Brian

---

From: Robert Sparks <[email-masked]>
Date: Wed, 27 Feb 2013 16:02:13 -0600

> We can fix 1 at AUTH48 if WGLC proceeds.
We'll have opportunity to revise the draft earlier than AUTH48.
>> 2)	The document gives no background material on why IETF review has been chosen, only that it no longer needs to be standards track (Note that I am not convinced "Standards Track" was selected in…
IETF review is the better path in this case. We're still learning what 
the guidance we would give an expert reviewer (which would
go with specification required) - IETF review lets us move forward and 
discuss that as we go. If we actually do get many more
of these, and it becomes clear both what that guidance would look like 
and that we don't need IETF-wide review for other reasons, we could 
shift to Specification Required later.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Feb 2013 06:13:52 +0800

Mostly WFM.

At the risk of setting off another long debate with Keith, ISTM that 
this document should be marked as updating 4412. (In the same way that 
draft-ietf-sipcore-priority updates 3261.) Otherwise, someone reading 
4412 will have no hint that the policies established in that document 
have been changed.

	Thanks,
	Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Feb 2013 17:17:56 -0500

Yes, we will do that.

Brian

On Feb 27, 2013, at 5:13 PM, Paul Kyzivat <[email-masked]> wrote:

> Mostly WFM.
> 
> At the risk of setting off another long debate with Keith, ISTM that this document should be marked as updating 4412. (In the same way that draft-ietf-sipcore-priority updates 3261.) Otherwise, someone reading 4412 will have no hint that the policies established in that document have been changed.
> 
> 	Thanks,
> 	Paul
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 28 Feb 2013 02:05:19 +0100

Brian wrote:
> I don't
> think Specification Required is adequate -- I want IETF experts to review.

If it is specification required then IETF experts will review.

      Specification Required - Values and their meanings must be
            documented in a permanent and readily available public
            specification, in sufficient detail so that interoperability
            between independent implementations is possible.  When used,
            Specification Required also implies use of a Designated
            Expert, who will review the public specification and
            evaluate whether it is sufficiently clear to allow
            interoperable implementations.  The intention behind
            "permanent and readily available" is that a document can
            reasonably be expected to be findable and retrievable long
            after IANA assignment of the requested value.  Publication
            of an RFC is an ideal means of achieving this requirement,
            but Specification Required is intended to also cover the
            case of a document published outside of the RFC path.  For
            RFC publication, the normal RFC review process is expected
            to provide the necessary review for interoperability, though
            the Designated Expert may be a particularly well-qualified
            person to perform such a review.

So to be clear, it gets review as follows:

-	by the experts involved in the original public specification by some other organization
-	by the designated expert

I am not sure that the designated expert has to be a single expert - it could be several people - the ADs just need to put it in place.

Regards

Keith

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: 27 February 2013 20:13
> To: DRAGE, Keith (Keith)
> Cc: Adam Roach; SIPCORE; [email-masked]
> Subject: Re: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-
> 00
> 
> The document doesn't have to say why a particular management policy was
> chosen.  It has to be the appropriate policy that the IETF agrees on.  In
> this case, we think an Informational RFC is adequate to add a new
> namespace but doesn't define new protocol behavior.  We think IETF Review
> is appropriate, so that we get review by the rather distributed
> constituency that cares about this particular piece of stuff.  I don't
> think Specification Required is adequate -- I want IETF experts to review.
> I don't even think Expert Review is adequate, because we do have several
> different classes of people who care about various aspects of this.
> 
> While I somewhat agree that 4412 is light on text defining when a new
> namespace is appropriate, it isn't the purpose of this document to rewrite
> that text, but rather to fix a specific problem that holds up other RFCs.
> If the policy is left at Standards Track, it still doesn't define when a
> new namespace is appropriate.  It still doesn't define whether an update
> to an existing namespace is required.
> 
> We could start an effort to do a 4412-bis to address these issues, but I
> would prefer not to turn this document into that.
> 
> Brian
> 
> 
> > I do not have a problem with relaxing the criteria and therefore we will
> need an I-D to do that, and therefore a milestone to cover that task.
> >
> > 1)	Editorial. The document states internally that it updates RFC 4412
> and this is correct. However that information also needs to appear in the
> top left of the document.
> >
> > 2)	The document gives no background material on why IETF review has
> been chosen, only that it no longer needs to be standards track (Note that
> I am not convinced "Standards Track" was selected in error). Personally I
> think "Specification Required" would be entirely appropriate, however if
> this is used see comment 3) below.
> >
> > 3)	As more relaxed criteria for IANA registration are defined, then
> material has to be defined to support those reviewing the registration;
> for a standards track defined protocol, this should be defined in a
> standards track document. For example RFC 4412 contains no information on
> when a new namespace is appropriate, as opposed to reuse of an existing
> namespaces. I have certainly been involved in discussions as to whether
> the "ETS" namespace is restricted only to usage of "US government
> telecommunications service" or whether another government body in a
> different country with identical requirements can reuse the same namespace,
> or whether they have to define a new namespace, and RFC 4412 does not
> answer this. So the proposed update currently contains no additional
> information (to RFC 4412) on:
> >
> > -	what criteria need to be met for adopting a new namespace or
> priority level, versus reusing or modifying an existing one.
> >
> > 4)	Can a new document update an existing namespace with new priority
> levels or other functionality? I believe this would normally be bad
> practice for compatibility reasons, but the document does not cover this.
> >
> > Keith
> >
> >