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

[Laura Liess <[e-mail]>]

2014-06-04 21:31 GMT+02:00 Dale R. Worley <[e-mail]>:

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


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



>
> [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.)
> ----------------------------------------------------------------------
>
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
>