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

worley@ariadne.com (Dale R. Worley) Thu, 05 June 2014 18:19 UTC

Return-Path: <worley@ariadne.com>
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 167BC1A02B5 for <salud@ietfa.amsl.com>; Thu, 5 Jun 2014 11:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
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 xG-F4KI4nWxu for <salud@ietfa.amsl.com>; Thu, 5 Jun 2014 11:19:47 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCFF1A02DC for <salud@ietf.org>; Thu, 5 Jun 2014 11:19:45 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id AcWE1o0041vXlb85FiKew5; Thu, 05 Jun 2014 18:19:38 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta17.westchester.pa.mail.comcast.net with comcast id AiKe1o00S1KKtkw3diKe9V; Thu, 05 Jun 2014 18:19:38 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s55IJbBw019197; Thu, 5 Jun 2014 14:19:37 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s55IJbTN019196; Thu, 5 Jun 2014 14:19:37 -0400
Date: Thu, 5 Jun 2014 14:19:37 -0400
Message-Id: <201406051819.s55IJbTN019196@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <CACWXZj22FDrBW6sGH1gn1iVCCZFpDvXrtsLVP-q1EV2gtEBCvA@mail.gmail.com> (laura.liess.dt@googlemail.com)
References: <201406041931.s54JVUfD014598@hobgoblin.ariadne.com> <CACWXZj22FDrBW6sGH1gn1iVCCZFpDvXrtsLVP-q1EV2gtEBCvA@mail.gmail.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401992378; bh=ZIDd39Dhhe1dTmbUppbpPbr1PkSiL18Z0meUyQLRr1M=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=huCbUtHdX6XnrXxW1M6UWXCV8FUA7fRVD6ziGPBZWPYii5L9I3Hc+FE5yeP7/sRl2 TcrBvZhD+bdzD052e/pmOqWOYM45Pl4vXV/t1J4M9SJCsdNswDQoVnBk2pybKP8CFb 8DG39gIN2AvoG70ff37m9QHUVyPvWx9scZbzebNn0ZwIIOhIZYaJ00KEP905Rtn31Y sE/h3CtFFEPk+c4Zc7Dm9I1cypl1KNrgrUG6JRRINHmgtB2QbZaJRmde0dMa5dt2BH Z/TFSh5RJ2q2mAWKQFVC4ilz3WRJqFoxql/UP+h0Xpd0aYD7kd3xJuaeZQhvSIqz2X a6LUcsFRlEXew==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/-jPrwuj-VdoHIC_wQgYbmkoPpgQ
Subject: Re: [salud] Second draft of changes for "specification required"
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: Thu, 05 Jun 2014 18:19:56 -0000

> From: Laura Liess <laura.liess.dt@googlemail.com>
>
> > Extensions, either standard or private, MUST (SHOULD?) conform to
> > the following principles:
> 
> 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?

> From: Paul Kyzivat <pkyzivat@alum.mit.edu>

> > Extensions, either standard or private, MUST (SHOULD?) conform to
> > the following principles:
> 
> MUST!

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 <pkyzivat@alum.mit.edu>
>
> >     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"?

Yes, the wording is unclear.

The -12 version has:

    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.

       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.

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

     10.1.  General Extension Rules

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

     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.

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.

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

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

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