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

worley@ariadne.com (Dale R. Worley) Wed, 14 May 2014 19:49 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 D972E1A02BC for <salud@ietfa.amsl.com>; Wed, 14 May 2014 12:49:11 -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 C0trWUhe8lGV for <salud@ietfa.amsl.com>; Wed, 14 May 2014 12:49:08 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id BC6171A02AC for <salud@ietf.org>; Wed, 14 May 2014 12:49:03 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta08.westchester.pa.mail.comcast.net with comcast id 1s1i1o0030EZKEL58vowbd; Wed, 14 May 2014 19:48:56 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta01.westchester.pa.mail.comcast.net with comcast id 1vow1o00X1KKtkw3MvowrG; Wed, 14 May 2014 19:48:56 +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 s4EJmttm025300; Wed, 14 May 2014 15:48:55 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s4EJmtMf025299; Wed, 14 May 2014 15:48:55 -0400
Date: Wed, 14 May 2014 15:48:55 -0400
Message-Id: <201405141948.s4EJmtMf025299@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <537261A4.8010505@alum.mit.edu> (pkyzivat@alum.mit.edu)
References: <20140509032842.32640.32550.idtracker@ietfa.amsl.com> <5371333C.1030201@alum.mit.edu> <CALaySJLSZs9=EMcsSj8r3bn8B_=zRWjtD9eBKjkA5FBSXDN1Aw@mail.gmail.com> <537261A4.8010505@alum.mit.edu>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1400096936; bh=PbcdxeO7QAQe7t+KWZoQVb56WtjOBDR0/j2ZfCDGyac=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=ECygrHYBFsYnSb+gkTR+PuS/cVWX/iAfRYgW17I1yqr3qH0FtO1Fye9Lt9IBbezgq eRRsHXsg4QtGBNb9z7SByv7KUccAb6iDe5PdXwPtWCX7gLdbfDhV+CNN8KLGiOGmxb wVRBjgzhkP26P8UIV0Bfs3usQt/Sr81RDnXsuoLe1B4+P4Db9lUqgvhoiVYlDIxF+b 9a0UiPk+HTM4nwTOVBGJk1tW07Czp8ZHfl9LyEIcD1409kONsumhUmzfPr8EM4Boaq mttXIT8UXqnfzRPEPYOxzBUETnc9L6KPbBYV4wUE7ngO+cjx13GXjv6ZwTckTfrtwf L4cW/xnbR5ooQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/lpr0clEcAHvTI_YwQuCBt5RUrBw
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 19:49:12 -0000

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