Re: [salud] First draft of changes for "expert review"

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 21 May 2014 16:13 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615DD1A072E for <salud@ietfa.amsl.com>; Wed, 21 May 2014 09:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4bciIGyFoOR for <salud@ietfa.amsl.com>; Wed, 21 May 2014 09:13:15 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 54A331A0346 for <salud@ietf.org>; Wed, 21 May 2014 09:13:15 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id 4c2v1o0031wpRvQ5DgDEyM; Wed, 21 May 2014 16:13:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 4gDE1o0083ZTu2S3egDEAr; Wed, 21 May 2014 16:13:14 +0000
Message-ID: <537CD09A.7050705@alum.mit.edu>
Date: Wed, 21 May 2014 12:13:14 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: salud@ietf.org
References: <201405192318.s4JNIKaH003254@hobgoblin.ariadne.com>
In-Reply-To: <201405192318.s4JNIKaH003254@hobgoblin.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1400688794; bh=IH2+8Uw8MBfD7Ff0XdfJNtxcdMS/8xAxpYphDEHN2+4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k8wVmXQm5ZJbfWLK2deRXh0x7F+W3ptbTaXZQP281i5zSqVtHqWmphCH+DoqduYO6 vQLeAyAsh7fbDVdTkBCSU8N9tI115b7k68vbx9cOAZ9Fqc/N8MtpKTOJMxQ4UlwTsj j8AEWoZLgbb2XgpSYkbyl4He855NPQNDqt0MAd1Ju3w+u981SUp5NWLDmgX2isky4W oL8svRNDXDBJkb/vcNy4U/sIWMyNojC/e9uqThNnCA/Yd7rOOVEucglTeg8Un3YFXA BG/+af3PwQtXoqJ0ikOTx3eBqCDr1HMsEhAo4NlLl4tvggZHyHdHJ92eGbka0NpPMP fhy1iTImeI/Lg==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/7phlZLHyxogfk2aAbunwfvMVplw
Subject: Re: [salud] First draft of changes for "expert review"
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 16:13:20 -0000

On 5/19/14 7:18 PM, Dale R. Worley wrote:
> [as an author]
>
> This is a first draft of changes needed to change the control of
> alert-info URNs from "Standards Action" to "Expert Review".  I think
> I've found all places in the text that would need to be modified.

I've looked at 5226, and I think we might want Specification Required 
rather than Expert Review. Specification Required also calls for expert 
review, but in addition requires there to be a publicly available 
specification.

More below.

> The important question is whether I've captured all of the guidelines
> that will be needed by the expert, which are listed in section 10.1.
>
> What do people think?
>
> Dale
>
> ----------------------------------------------------------------------
>     9.1.  Registry
>
>     ...
>     The policy for adding a new standard <alert-category> is 'Standards
>     Action'.  The policy for adding <alert-identifiers>s or patterns of
>     <alert-identifiers>s within a particular <alert-category> may differ
>     for each <alert-category>and MUST be defined by the document defining
>     the corresponding <alert-category>.
>
> The policy for adding a new standard <alert-category> or a new
> standard <alert-identifiers>, or pattern of <alert-identifiers>s

s/identifiers/identifier/

> within a particular <alert-category> is Expert Review according to the
> guidelines in section 10.1.
>
>     9.2.  Initial IANA Registration
>
>     This document defines the <alert-category>s 'service', 'source',
>     'priority', 'duration', 'delay' and 'locale'.  The policy for adding
>     an <alert-identifier> for any of these <alert-category>s is Standards
>     Action.
>
> Delete the last sentence.
>
>     ...
>     10.  Extension Rules
>
>     10.1.  General Extension Rules
>
>     The set of "alert" URNs is extensible.  An extension "at the top
>     level" creates an new <alert-category> (which represents a new
>     alerting characteristic), an extension "at the second level" creates
>     a new <alert-indication> value for an existing <alert-category> , an
>     extension "at the third level" creates a subdivision of an existing
>     <alert-indication> (that has one <alert-ind-part> ), etc.  URNs allow
>     (in principle) indefinite subdivision of existing <alert-indication>
>     values, although most of the standard "alert" URNs have only one
>     level of subdivision and a few have two levels of subdivision.
>
>     Designers of extensions should take care to derive the new URN from
>     the most specific base URN which has the correct meaning; a new URN
>     should have no semantic overlap with any sibling URN, i.e., there can
>     be no calls to which both URNs could apply.
>
> Replace the preceding paragraph with:
>
> Extensions, either standard or private, MUST (*** SHOULD?) conform to
> the following principles:
>
> [The following sentences use "is" and "are" rather than "must",
> "should", "can", etc.  That allows the strength of these statements to
> be determined only by the RFC 2119 word in the preceding sentence, and
> prevents these statements from setting their own strength.]
>
> A new <alert-category> is independent of all previously-existing
> <alert-category>s; there are potentially calls to which all
> combinations of <alert-identifier>s in the new <alert-category> with
> all <alert-identifier>s in all previously-existing <alert-category>s
> can be applied.

"can be meaningfully applied."

> A new <alert-identifier> that has more than one <alert-ind-part> is
> the extension of a parent <alert-identifier>, which is determined by

Is "extension" the right word here?
I think perhaps "refinement" or "narrowing".

The change will also apply below.

> deleting the final <alert-ind-part>.  The new <alert-identifier> must
> be the extension of the most specific previously-existing
> <alert-identifier> whose meaning includes all potential calls to which
> the new <alert-identifier> could be applied.
>
> A new <alert-identifier> has no semantic overlap with any sibling
> <alert-identifier> (<alert-identifier>s that differ only in the final
> <alert-ind-part>).  I.e., there could be no call to which both
> <alert-identifier>s could apply.
>
>     The process for defining new standard "alert" URNs is described in
>     Section 9.1.  Currently, all such definitions require Standards
>     Action.  The process for defining new "alert" URNs via the private
>     extension mechanism is described in Section 10.2.
>
> The second sentence becomes:  All such definitions require Expert
> Review.
>
>     10.2.  Private Extension Rules
>
>     ...
>     Creating private extension "alert" URNs is not a Standards Action and
>     they are not registered with IANA.
>
>     Once an organization obtains the right to use a particular <provider>
>     for constructing <private-name>s, it will retain that right forever,
>     unless it transfers that right to another organization.  The
>     organization defining a private extension is responsible for ensuring
>     persistence of the meaning of the private extension, and for ensuring
>     that the private extension does not duplicate any standard URN or any
>     private extension that the organization is aware of.  (In either
>     case, the organization SHOULD use the existing URN for its purposes.)
>
> Replace the preceding paragraph with:

I previously commented on this.

	Thanks,
	Paul

> The organization defining a private extension is responsible for
> ensuring persistence of the meaning of the private extension.
>
> Private extensions MUST (*** SHOULD?) conform to the principles of
> section 10.1, both in regard to previously-existing standard
> <alert-URN>s and in regard to any previously-existing private
> extensions using the same <provider> value, and any other private
> extensions that the organization is aware of.  In particular, a
> private extension MUST not duplicate any standard URN or any private
> extension that the organization is aware of.  (In either case, the
> organization MUST use the existing URN for its purposes.)
> ----------------------------------------------------------------------
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>