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

["Rosen, Brian" <[e-mail]>]

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


On Feb 27, 2013, at 2:48 PM, "DRAGE, Keith (Keith)" <[e-mail]> wrote:

> 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: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Adam Roach
>> Sent: 27 February 2013 16:36
>> To: 'SIPCORE'
>> Cc: [e-mail]
>> Subject: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00
>> 
>> [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
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore