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

worley@ariadne.com (Dale R. Worley) Tue, 07 January 2014 20:33 UTC

Return-Path: <worley@shell01.TheWorld.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 DD04B1AE187 for <salud@ietfa.amsl.com>; Tue, 7 Jan 2014 12:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 cosk7QX08S20 for <salud@ietfa.amsl.com>; Tue, 7 Jan 2014 12:33:25 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id E381C1AE15B for <salud@ietf.org>; Tue, 7 Jan 2014 12:33:24 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s07KWZXY003893; Tue, 7 Jan 2014 15:32:37 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s07KWYJq2344359; Tue, 7 Jan 2014 15:32:34 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s07KWYwn2340453; Tue, 7 Jan 2014 15:32:34 -0500 (EST)
Date: Tue, 07 Jan 2014 15:32:34 -0500
Message-Id: <201401072032.s07KWYwn2340453@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-reply-to: <528D41F2.8090200@alum.mit.edu> (pkyzivat@alum.mit.edu)
References: <201311201944.rAKJiS7d5355422@shell01.TheWorld.com> <528D41F2.8090200@alum.mit.edu>
Cc: 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: Tue, 07 Jan 2014 20:33:27 -0000

Here is my revision of section 9.2 (the examples) based on Paul's
suggestions.  It can be compared directly with the text in -09.


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 four 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:  internal

   Signals at source: (tied for second place)

      Signal 3:  low
      Signal 4:  high
      Signal 5:  default

   And these signals are excluded from the set:

      Signal 1:  external

   So in this example, the sorting algorithm properly gives first place
   to Signal 2 "internal".

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:  internal
      Signal 8:  internal high

   Signals at source: (tied for second place)

      Signal 4:  low
      Signal 5:  high
      Signal 1:  default

   Signals excluded from the set:

      Signal 2:  external
      Signal 7:  external low
      Signal 6:  external high

   Two signals are tied for the first place, but the final sort orders
   them:

      Signal 3:  internal
      Signal 8:  internal high

   because it puts the least-specific signal first.  So Signal 3
   "internal" 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:  external
      Signal 7:  external low
      Signal 6:  external high

   Signals at source:

      Signal 4:  low
      Signal 5:  high
      Signal 1:  default

   Signals excluded:

      Signal 3:  internal
      Signal 8:  internal high

   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:  external low
      Signal 2:  external
      Signal 4:  low
      Signal 1:  default

   Excluded:

      Signal 6:  external high
      Signal 5:  high
      Signal 3:  internal
      Signal 8:  internal high

   So, Signal 7 "external low" is chosen.

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:  internal
      Signal 8:  internal high
      Signal 4:  low
      Signal 5:  high
      Signal 1:  default

   Excluded:

      Signal 2:  external
      Signal 7:  external low
      Signal 6:  external high

   The second sort is based on priority:low, and results in this order:

      Signal 3:  internal
      Signal 4:  low
      Signal 1:  default

   Excluded:

      Signal 8:  internal high
      Signal 5:  high
      Signal 7:  external low
      Signal 2:  external
      Signal 6:  external high

   So Signal 3 "internal" is chosen.

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:  low
      Signal 1:  default

   Excluded:

      Signal 3:  high

   and Signal 2 "low" is chosen.

   Similarly, if the device receives <urn:alert:priority:high>, Signal 3
   "high" is chosen.

   If the device receives <urn:alert:priority:normal>, the sort is:

      Signal 1:  default

   Excluded:

      Signal 2:  low
      Signal 3:  high

   and Signal 1 "default" is chosen.

   If no "priority" URN is received, Signal 1 "default" will be put
   before Signal 2 "low" and Signal 3 "high" by the final sort, and so
   it will be chosen.


Dale