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

From: [email-masked] (Dale R. Worley)
Date: Wed, 4 Jun 2014 15:31:30 -0400

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

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

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

---

From: Laura Liess <[email-masked]>
Date: Thu, 5 Jun 2014 15:32:19 +0200

> Dale

I think if we don't want extenssions which do not comply to these
princilpes we should use MUST.  Or do we want to allow exceptions?

If we use SHOULD, what happens if someone wants an extenssion which does
not comply. Is the designated expert allowed to reject the extenssion
because it does not comply? Or is a source for never ending discussions?

Thank you
Laura

> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Jun 2014 11:20:09 -0400

> There is also a question about the use of MUST vs. SHOULD in several

MUST!

> The second sentence becomes:  All such definitions require Expert

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

> 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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 5 Jun 2014 14:19:37 -0400

> From: Laura Liess <[email-masked]>
>

> From: Paul Kyzivat <[email-masked]>

> > the following principles:

Based on both your comments, I agree that we want MUST.  Otherwise,
people will try to get approval for poorly-designed extensions.

> From: Paul Kyzivat <[email-masked]>
>

Yes, the wording is unclear.

The -12 version has:

    10.  Extension Rules

I'm proposing that we make the rules more explicit, to provide
guidance to the Designated Expert.  That changes section 10.1 to:

     10.  Extension Rules

The first paragraph is unchanged, or mostly unchanged.  Its goal is to
give the reader the overall concept of the extension mechanism.

What was the second paragraph of 10.1 becomes the following 4
paragraphs.  (I've improved the second of these paragraphs since my
previous message.  I think it is now clear enough.)

     Extensions, either standard or private, MUST conform to the
     following principles:

     A new <alert-category> is independent of all previously-existing
     <alert-category>s:  For any combination of one <alert-identifier>
     in the new <alert-category> with one <alert-identifier> in any of
     the previously-existing <alert-category>s, there are potential
     calls to which the combination can be meaningfully applied.

The old third paragraph becomes as follows.  (I've connected the first
and second sentences with a semicolon.  I believe that makes it
clearer that the things that require Expert Review are new standard
URNs.)

     The process for defining new standard "alert" URNs is described
     in Section 9.1; all such definitions require Expert Review.  The
     process for defining new "alert" URNs via the private extension
     mechanism is described in Section 10.2.

Perhaps "process" should be changed to "procedure".

The previous paragraph gives pointers to the sections that describe
the procedures for establishing a new URNs.  Section 9.1 describes the
registry for alert URNs.  Section 10.2 gives "Private Extension
Rules".

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

That is correct in principle.  But I do not believe that changing the
definition of <provider> will change any of the text we are
discussing; we can discuss the two topics independently.

Dale