Re: [salud] Barry Leiba's Discuss on draft-ietf-salud-alert-info-urns-12: (with DISCUSS and COMMENT)

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 14 May 2014 20:36 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 EA9F31A013A for <salud@ietfa.amsl.com>; Wed, 14 May 2014 13:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 AkXs03ePLTMB for <salud@ietfa.amsl.com>; Wed, 14 May 2014 13:36:45 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 628751A00AE for <salud@ietf.org>; Wed, 14 May 2014 13:36:45 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id 1vdJ1o0041HzFnQ59wce2o; Wed, 14 May 2014 20:36:38 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id 1wce1o0043ZTu2S3awceiL; Wed, 14 May 2014 20:36:38 +0000
Message-ID: <5373D3D5.50901@alum.mit.edu>
Date: Wed, 14 May 2014 16:36:37 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: salud@ietf.org
References: <20140509032842.32640.32550.idtracker@ietfa.amsl.com> <5371333C.1030201@alum.mit.edu> <CALaySJLSZs9=EMcsSj8r3bn8B_=zRWjtD9eBKjkA5FBSXDN1Aw@mail.gmail.com> <537261A4.8010505@alum.mit.edu> <201405141948.s4EJmtMf025299@hobgoblin.ariadne.com>
In-Reply-To: <201405141948.s4EJmtMf025299@hobgoblin.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1400099798; bh=ABSTy32bDog6WrpUn8PQN+UkHSg+wKdbK959dKwmhU4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PiEtW1NcN3O4ccDQ8UV85pPj/A85gNDqjoYcrPniKhJyW9JJI3xIBOTkpJzwEMELe RqCgNVgmO54m7bXC3yxBlKRLHdKIDh99PNF04z5FI6ZzEwldaPN7o7ru5ElahqLMsw qsR5uoepef0NjGPJBUY3qPKzMLRtvRjXHMQYnLFAW+Dcx+pQUGqUM5H3ckY3rNdi0I TaXyyIfQ9TLZagqHQwT7A2G/Tpz6Z3g1YVjMMEZ5n6WxkU+XTEvqkFdtTEsy07IOBo 1E5YCe3dg+oz+vF6D55xEP2jEgYDzYRCUSxiVQ5INVCQEec2VIL/HkfIn3HasHj+tO PLUoItaMaK7+w==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/Tg4B5p2cGlKc964tjtxy25RiDJA
Subject: Re: [salud] Barry Leiba's Discuss on draft-ietf-salud-alert-info-urns-12: (with DISCUSS and COMMENT)
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: Wed, 14 May 2014 20:36:47 -0000

Thanks Dale. Your additions below are good.

The real question is: do we want to justify keeping standards action, or 
do we want to relax to something that can be approved by an expert and 
define the rules for the expert?

	Thanks,
	Paul

On 5/14/14 3:48 PM, Dale R. Worley wrote:
>> [NOTE: this message is to the WG, not back to Barry.]
>
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>
>>> Are you saying that we don't *know* what guidance to give to the
>>> expert?  Then how would we expect an individually submitted Standards
>>> Track draft to get any reasonable processing for this?
>>
>> What I am tempted to reply is:
>>
>> ===
>>
>> Yep, that is what I'm saying.
>>
>> I would hope that these would be run through a WG - probably DISPATCH
>> once SALUD closes. And there the pros/cons would be debated.
>>
>> Else it would presumably be AD-sponsored, and the AD would be the
>> sounding board.
>>
>> We could spend more time trying to define guidelines for an expert. But
>> it is not so each. Each category is a new dimension in a
>> multidimensional space, with a unique domain of values. We want the
>> dimensions to be independent, so that there aren't multiple ways to
>> express the same thing. And there are better and worse ways to define
>> things, and some things that make no sense at all. It is hard to
>> describe "common sense" here.
>>
>> ===
>>
>> But that might not be a wise thing to answer to the iesg.
>
> Here are are some additions to what you've said.
>
>      Yep, that is what I'm saying.  The problem is that it's easier to
>      solve a specific instance of a problem (in this case, what to do with
>      a URN extension proposal) than it is to provide an algorithm (in
>      effect) for solving all possible future instances of the problem.
>
>      I would hope that these would be run through a WG - probably DISPATCH
>      once SALUD closes. And there the pros/cons would be debated.
>
>      Else it would presumably be AD-sponsored, and the AD would be the
>      sounding board.
>
>      We could spend more time trying to define guidelines for an
>      expert. But it is not so easy to do that. Each category is a new
>      dimension in a multidimensional space, with a unique domain of
>      values. We want the dimensions to be independent, so that there aren't
>      multiple ways to express the same thing. And there are better and
>      worse ways to define things, and some things that make no sense at
>      all.  In addition, we want the alert-info URN system to be
>      semantically compatible with existing practices in the rest of the
>      telecom universe to maximize interoperability.  It is hard to describe
>      "common sense" here, and there is a risk that some important
>      requirement would not be noticed until a proposal was submitted which
>      violates the requirement.
>
> I tried to start a list of directions to an expert.  So far, I've got:
>
> - A new alert-category should be independent of existing
>    alert-categories, i.e., that each alert-identifier of the new
>    alert-category can be meaningfully combined with any
>    alert-identifiers of all existing alert-categories.
>
> - A new alert-category should not specify information that can already
>    be specified by existing alert-categories.
>
> - A new alert-category should not reduce compatibility with existing
>    practices in the telecommunications industry.
>
> Though now that I think of it, the rules are in (or should be in)
> sections 10.1 and 10.2, which define the restrictions on creating
> private extensions.  We may have already done this work.  Or maybe,
> finishing this work may be needed to make 10.1 and 10.2 correct.
>
> Dale
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>