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

[Robert Sparks <[e-mail]>]

repeating a thought just to make sure it was seen in this context

On 2/27/13 7:05 PM, DRAGE, Keith (Keith) wrote:
> 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.
That means we have a small number of people that we could identify to 
delegate review to for the whole community, and the community would 
trust they would see all the potential issues a proposal brings. In this 
case, I think we're not there yet, and
actually _do_ want full community review. As I said before, I think the 
right thing to do is take incremental steps with this one.
Get some experience with IETF review, and shift to something that only 
required expert review later.
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: Rosen, Brian [mailto:[e-mail]]
>> Sent: 27 February 2013 20:13
>> To: DRAGE, Keith (Keith)
>> Cc: Adam Roach; SIPCORE; [e-mail]
>> Subject: Re: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-
>> 00
>>
>> 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)" <keith.drage@alcatel-
>> lucent.com> 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
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore