Re: [salud] WGLC of draft-ietf-salud-alert-info-urns-09

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 06 January 2014 16:54 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 36CDA1AE0F7 for <salud@ietfa.amsl.com>; Mon, 6 Jan 2014 08:54:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.065
X-Spam-Level: **
X-Spam-Status: No, score=2.065 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_84=0.6, 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 23wo-WZKEyiJ for <salud@ietfa.amsl.com>; Mon, 6 Jan 2014 08:54:38 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0E21AE069 for <salud@ietf.org>; Mon, 6 Jan 2014 08:54:37 -0800 (PST)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id Ad1U1n0030cZkys54guVwM; Mon, 06 Jan 2014 16:54:29 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id AguV1n00B3ZTu2S3WguVKh; Mon, 06 Jan 2014 16:54:29 +0000
Message-ID: <52CADFC5.7060100@alum.mit.edu>
Date: Mon, 06 Jan 2014 11:54:29 -0500
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.2.0
MIME-Version: 1.0
To: Laura Liess <laura.liess.dt@googlemail.com>
References: <201311201944.rAKJiS7d5355422@shell01.TheWorld.com> <528D41F2.8090200@alum.mit.edu> <CACWXZj39wsahY-=VN1e7a=wLK_55H=oVYkeSbRrUce+jMzH_Vg@mail.gmail.com>
In-Reply-To: <CACWXZj39wsahY-=VN1e7a=wLK_55H=oVYkeSbRrUce+jMzH_Vg@mail.gmail.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=q20121106; t=1389027269; bh=t0++voq14XtWBIZE4slDsj5j/2W3HYvs2WkXcnrPTpg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=at2sCW315SZNKtWy99qkYfF5Y+LKpFDLei6c4//+6NCZ+DNytPBfsZuHXZs5BXasM KZvElDvKupbG7TDv4u0bbjBrGG9nL+iI0+0IfMOhE9wq/SWEHfp2TRhfT5VhKg7HOa dbbtIkNWRRNPgA4Ue0AVFGhiyAy7JJ0rde6N8cCwSmi8Xzvor9VX+1D/86QdkLN79b 6Gqiyea8G/rjOsO6jZs12yDZe1W7rPvJDyZ2EvJJu6VDcR6PdXfvjRmXoTWdxl7Kvs L9I/lWeJqWyTTKfscFGG8V5mQWWzHwLcsINpKKP0KYitxbQrjSFUqRHkdPKVrTmB8T R+hHg5WSgNXUQ==
Cc: "salud@ietf.org" <salud@ietf.org>
Subject: Re: [salud] WGLC of draft-ietf-salud-alert-info-urns-09
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, 06 Jan 2014 16:54:40 -0000

Laura,

This all sounds good to me. I would like to have Dale also verify it.

	Thanks,
	Paul

On 1/6/14 3:37 AM, Laura Liess wrote:
>
> Paul,
>
> Thank you for the comments. Please see inline.
>
> 2013/11/21 Paul Kyzivat <pkyzivat@alum.mit.edu
> <mailto:pkyzivat@alum.mit.edu>>
>
>
>
>     Section 4:
>
>            Registration date:  TBD
>
>     How is this to be filled in? Should there be instructions to the editor?
>
>
>  From the RFC 3406 Annex B.2, my understanding is that we should send
> the registration request to IANAafter IESG approves the draft for
> publication.
>
> I would replace the "TBD" in the Registration date  by <when submitted>,
> as shown in the Annex B.1 "Example Template" of the RFC 3406.  Is this
> OK for you?
>
> Text from the RFC 3406:
>
> B.2 Registration steps in practice
>
>     The key steps for registration of informal or formal namespaces
>     typically play out as follows:
>
>
> ..............................
>
>     Formal NID:
>
>        1. Write an Internet-Draft describing the namespace and include
>           the registration template, duly completed.  Be sure to include
>           "Namespace Considerations", "Community Considerations" and
>           "IANA Considerations" sections, as described in Section 4.3.
>
>        2. Send the Internet-Draft to the I-D editor, and send a copy to
>           urn-nid@apps.ietf.org  <mailto:urn-nid@apps.ietf.org>  for technical review.
>
>        3. Update the Internet-Draft as necessary from comments, and
>           repeat steps 2 and 3 as needed.
>
>        4. Send a request to the IESG to publish the I-D as an RFC.  The
>           IESG may request further changes (published as I-D revisions)
>           and/or direct discussion to designated working groups, area
>           experts, etc.
>
>        5. If the IESG approves the document for publication as an RFC,
>           send a request to IANA to register the requested NID.
>
>
>
>
>
>
>
>     Section 9.2:
>
>     The examples are a but hard to follow. Specifically, each example
>     describes the signals at each source and the winner, but when doing
>     so it never mentions which signals (Signal 1, Signal 2, ...) - it
>     instead identifies by alert urn. Since to point is to determine the
>     signal to be rendered, this seems obscure. For example the following
>     would seem clearer to me for 9.2.1:
>
>         If the device receives <urn:alert:source:internal>, then the
>     sort is:
>
>         Signals at source:internal: (this is, first place)
>
>            Signal 2
>
>         Signals at source: (tied for second place)
>
>            Signal 3
>            Signal 4
>            Signal 5
>
>         And these signals are excluded from the set:
>
>            Signal 1
>
>         So in this example, the sorting algorithm properly gives first place
>         to Signal 2.
>
>     Section 10:
>
>         A SIP UA MAY add a URN or multiple URNs to the Alert-Info header
>         field in a SIP request or a provisional 1xx response (excepting
>     a 100
>         response) when it needs to provide additional information about the
>         call or about the provided service.
>
>     The above only talks about adding *to* an Alert-Info, not the adding
>     *of* an Alert-Info. I suggest:
>
>         A SIP UA MAY include one or more Alert-Info header fields,
>         containing one or more URNs in a SIP request or a provisional 1xx
>         response (excepting a 100 response) when it needs to provide
>         additional information about the call or about the provided service.
>
> Agree. Please find below the modified  Section  9.2 modified
> accordingly. Please let me know if you find inconsistencies in the
> modified version.
>
> 9.2.Examples of How the Algorithm Works
>
> The following examples show how the algorithm described in the
> previous section works:
>
> 9.2.1.Example 1
>
> The device has a set of 4 alerting signals.We list their primary
> meanings, and the locations that they are placed in the feature
> trees:
>
> Signal 1
>
> Meaning: external
> Locations:
> - source:external
> - priority (that is, the root node of the priority tree)
>
> Signal 2
>
> Meaning: internal
> Locations:
> - source:internal
> - priority
>
> Signal 3
>
> Meaning: low
> Locations:
> - source
> - priority:low
>
> Signal 4
>
> Meaning: high
> Locations:
> - source
> - priority:high
>
> To which we add:
>
> Signal 5
>
> Meaning: default
> Locations:
> - source
> - priority
>
> If the device receives <urn:alert:source:internal>, then the sort is:
>
> Signals at source:internal: (this is, first place)
>
> Signal 2
>
> Signals at source: (tied for second place)
>
> Signal 3
> Signal 4
> Signal 5
>
> And these signals are excluded from the set:
>
> Signal 1
>
> So in this example, the sorting algorithm properly gives first place
> to Signal 2.
>
> 9.2.2.Example 2
>
> Let us add to the set of signals in Example 1 ones that express
> combinations like "internal, high priority", but let us specifically
> exclude the combination "internal, low priority" so as to set up some
> tricky examples.This enlarges our set of signals:
>
> Signal 1
>
> Meaning: default
> Locations:
> - source
> - priority
>
> Signal 2
>
> Meaning: external
> Locations:
> - source:external
> - priority
>
> Signal 3
>
> Meaning: internal
> Locations:
> - source:internal
> - priority
>
> Signal 4
>
> Meaning: low
> Locations:
> - source
> - priority:low
>
> Signal 5
>
> Meaning: high
> Locations:
> - source
> - priority:high
>
> Signal 6
>
> Meaning: external high
> Locations:
> - source:external
> - priority:high
>
> Signal 7
>
> Meaning: external low
> Locations:
> - source:external
> - priority:low
>
> Signal 8
>
> Meaning: internal high
> Locations:
> - source:internal
> - priority:high
>
> If the device receives <urn:alert:source:internal>, then the sort is:
>
> Signals at source:internal: (that is, tied for first place)
>
> - Signal 3
> - Signal 8
>
> Signals at source: (tied for second place)
>
> - Signal 4
> - Signal 5
> - Signal 1
>
> Signals excluded from the set:
>
> - Signal 2
> - Signal 7
> - Signal 6
>
> Two signals are tied for the first place, but the final sort orders
> them:
>
> - Signal 3
> - Signal 8
>
> because it puts the least-specific signal first.So the Signal 3 is
> chosen.
>
> 9.2.3.Example 3
>
> The same device receives <urn:alert:source:external>,
> <urn:alert:priority:low>.The first sort (due to
> <urn:alert:source:external>) is:
>
> Signals at source:external:
>
> - Signal 2
> - Signal 7
> - Signal 6
>
> Signals at source:
>
> - Signal 4
> - Signal 5
> - Signal 1
>
> Signals excluded:
>
> - Signal 3
> - Signal 8
>
> The second sort (due to <urn:alert:priority:low>) puts signals at
> priority:low before signals at priority, and excludes signal at
> priority:high:
>
> - Signal 7
> - Signal 2
> - Signal 4
> - Signal 1
>
> Excluded:
>
> - Signal 6
> - Signal 5
> - Signal 3
> - Signal 8
>
> So, we choose Signal 7.
>
> 9.2.4.Example 4
>
> Suppose the same device receives <urn:alert:source:internal>,
> <urn:alert:priority:low>.Note that there is no signal that
> corresponds to this combination.
>
> The first sort is based on source:internal, and results in this
> order:
>
> - Signal 3
> - Signal 8
> - Signal 4
> - Signal 5
> - Signal 1
>
> Excluded:
>
> - Signal 2
> - Signal 7
> - Signal 6
>
> The second sort is based on priority:low, and results in this order:
>
> - Signal 3
> - Signal 4
> - Signal 1
>
> Excluded:
>
> - Signal 8
> - Signal 5
> - Signal 7
> - Signal 2
> - Signal 6
>
> So we choose the Signal 3.Note that <urn:alert:priority:low> could
> not be given effect because it followed <urn:alert:source:internal>.
> If the two URNs had appeared in the reverse order, the Signal 2 would
> have been chosen, because <urn:alert:priority:low> would have been
> given precedence.
>
> 9.2.5.Example 5
>
> Let us set up a simple set of signals, with three signals giving
> priority:
>
> Signal 1
>
> Meaning: default
> Locations:
> - priority
>
> Signal 2
>
> Meaning: low
> Locations:
> - priority:low
>
> Signal 3
>
> Meaning: high
> Locations:
> - priority:high
>
> Notice that we've used the "default" signal to cover "normal
> priority".That is so the signal will cover situations where no
> priority URN is present, as well as the ones with
> <urn:alert:priority:normal>.So we're deliberately failing to
> distinguish "priority:normal" from the default priority.
>
> If the device receives <urn:alert:priority:low>, the sort is:
>
> - Signal 2
> - Signal 1
>
> Excluded:
>
> - Signal 3
>
> and Signal 2 is chosen.
>
> Similarly, if the device receives <urn:alert:priority:high>, Signal 3
> is chosen.
>
> If the device receives <urn:alert:priority:normal>, the sort is:
>
> -Signal 1
>
> Excluded:
>
> - Signal 2
> - Signal 3
>
> and Signal 1is chosen.
>
> If no "priority" URN is received, Signal 1 will be put before Signal
> 2 and Signal 3 by the final sort, and so it will be chosen.
>
>
>
>     Section 11:
>
>         A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header
>         field in a SIP request or a provisional 1xx response (excepting
>     a 100
>         response) when it needs to provide additional information about the
>         call or about the provided service.
>
>     I think we would ideally allow a proxy to modify/remove URNs, but
>     3261 doesn't permit that. But a proxy can get a similar effect by
>     putting a counteracting URN earlier in the sequence. But it is also
>     possible that there will be no Alert-Info and the proxy needs to add
>     one. I suggest:
>
>         A SIP proxy MAY add an Alert-Info header field if none is present,
>         and MAY add or remove URNs to an Alert-Info header
>         field in a SIP request or a provisional 1xx response (excepting
>     a 100
>         response) when it needs to provide additional information about the
>         call or about the provided service.
>
>
> Agree.
>
> Thank you
> Laura
>
>
>              Thanks,
>              Paul
>     _______________________________________________
>     salud mailing list
>     salud@ietf.org <mailto:salud@ietf.org>
>     https://www.ietf.org/mailman/listinfo/salud
>
>