Re: [salud] Second draft of changes for "specification required"

[Paul Kyzivat <[e-mail]>]

On 6/4/14 3:31 PM, Dale R. Worley wrote:
> [as an author]
>
> This is a second draft of the changes needed to change the policy for
> alert-info URNs from "Standards Action" to "Specification Required".
> I think I've found all places in the text that would need to be
> modified.  I've incorporated the changes suggested by Paul and
> clarified the language in a few places.
>
> (Reading the description of "Specification Required" in RFC 5226, it
> seems that usually the specification will be an RFC.  But the RFC
> could be AD-sponsored, or I suppose, independent, which saves quite a
> bit of overhead compared to "Standards Action".)
>
> An 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.
>
> There is also a question about the use of MUST vs. SHOULD in several
> places.
>
> 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>.
>
> Replace this with:
>
> The policy for adding a new standard <alert-category>, or, within a
> particular <alert-category>, a new standard <alert-identifier> or
> pattern of <alert-identifier>s is 'Specification Required' 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:

MUST!

> [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 meaningfully applied.
>
> A new <alert-identifier> that has more than one <alert-ind-part> is a
> semantic refinement of a parent <alert-identifier>, the parent being
> obtained by deleting the final <alert-ind-part>.  The new
> <alert-identifier> has as parent 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 meaningfully 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.

I think I am losing the big picture here of how the standard and private 
definitions relate. I think I need to look at this all together in a new 
version of the draft. Is this new second sentence intended to apply only 
to standard extensions? Why is this paragraph not in a section titled 
"Standard Extension Rules"?

>     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:
>
> 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 (SHOULD?) not duplicate any standard URN or any
> private extension that the organization is aware of.  (In either case,
> the organization MUST (SHOULD?) use the existing URN for its purposes.)
> ----------------------------------------------------------------------

Am I right that this is not (yet) dealing with a change to registering 
<provider>s?

	Thanks,
	Paul