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

["DRAGE, Keith (Keith)" <[e-mail]>]

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

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