[salud] First draft of changes for "expert review"
worley@ariadne.com (Dale R. Worley) Mon, 19 May 2014 23:18 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 0375B1A018A for <salud@ietfa.amsl.com>; Mon, 19 May 2014 16:18:25 -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 rRhZgQDr1Xq5 for <salud@ietfa.amsl.com>; Mon, 19 May 2014 16:18:23 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 64B711A0194 for <salud@ietf.org>; Mon, 19 May 2014 16:18:23 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta06.westchester.pa.mail.comcast.net with comcast id 3yy11o0061GhbT856zJN3e; Mon, 19 May 2014 23:18:22 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta07.westchester.pa.mail.comcast.net with comcast id 3zJN1o00M1KKtkw3TzJNbh; Mon, 19 May 2014 23:18:22 +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 s4JNIL9R003255; Mon, 19 May 2014 19:18:21 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s4JNIKaH003254; Mon, 19 May 2014 19:18:20 -0400
Date: Mon, 19 May 2014 19:18:20 -0400
Message-Id: <201405192318.s4JNIKaH003254@hobgoblin.ariadne.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: salud@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1400541502; bh=NHy6rp4KkMmE4LrMsoGrJssMcGIhhh6S8AlF9aCZ1IY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=gpNGq1conUxeN2PZq4xtNADLRAosPRH3H0c++v23Wktfg5oegBBZSZEne0G9I1a/s ChdQ+5f3znRR6gMHtW11Q6fNOaNEfGENbfyKXUAkluFHKbxaVQESH3xrJwIxl9tqo9 vFesFNVK0/W0GogoGlLdaQIn/i0AK2mscj4cWwE7Lloj8MP+5wnufOrw3GdLZOnRFs MXqlL5jNvkhQjaP4alCBAXZi6rs601QHeTqUxzb+DjbUzsiwVFeWRFF6+QpD+caiWp vl2l7N99wkbB1vi8eIfVCcpvx4yKGXrRB0CwuxRqnUimsf0Z59RsAl04CxigM+J8b8 FwDSZpkarmJIA==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/OUDOJqM5eOEKXJtC7nD9VBehhvQ
Subject: [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: Mon, 19 May 2014 23:18:25 -0000
[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. 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 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. A new <alert-identifier> that has more than one <alert-ind-part> is the extension of a parent <alert-identifier>, which is determined by 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: 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] First draft of changes for "expert review" Dale R. Worley
- Re: [salud] First draft of changes for "expert re… Paul Kyzivat
- Re: [salud] First draft of changes for "expert re… Dale R. Worley