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

From: Laura Liess <[email-masked]>
Date: Mon, 6 Jan 2014 09:37:35 +0100

Paul,

Thank you for the comments. Please see inline.

2013/11/21 Paul Kyzivat <[email-masked]>

>
>
> 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
         [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jan 2014 11:54:29 -0500

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:
> 2013/11/21 Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>>
>
>
>
>     Section 4:
>
>            Registration date:  TBD
>
>  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:
>
>           [email-masked]  <mailto:[email-masked]>  for technical review.
>
>     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:
>
>     The above only talks about adding *to* an Alert-Info, not the adding
>     *of* an Alert-Info. I suggest:
>
> 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
>
> 9.2.1.Example 1
> The device has a set of 4 alerting signals.We list their primary
> 9.2.2.Example 2
> 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
>
> because it puts the least-specific signal first.So the Signal 3 is
> chosen.
>
> 9.2.3.Example 3
>
> <urn:alert:priority:low>.The first sort (due to
> 9.2.4.Example 4
> <urn:alert:priority:low>.Note that there is no signal that
> So we choose the Signal 3.Note that <urn:alert:priority:low> could
> 9.2.5.Example 5
> priority".That is so the signal will cover situations where no
> <urn:alert:priority:normal>.So we're deliberately failing to
>     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:
>
>     [email-masked] <mailto:[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 7 Jan 2014 15:07:51 -0500 (EST)

I've been neglecting Salud...

> Date: Wed, 20 Nov 2013 15:12:50 -0800
> From: Paul Kyzivat <[email-masked]>

My comments on items in this message.  (The other items I agree with.)

> How is this to be filled in? Should there be instructions to the editor?

The common method (e.g., draft-cardona-cablelabs-urn-02.txt) seems to
be:

        Registration date: YYYY-MM-DD [RFC Editor: Please replace YYYY-
        MM-DD with the publication date of this RFC.]

> Section 9.2:
> 
> The examples are a [bit] 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 
> rendered, this seems obscure. For example the following would seem 
> clearer to me for 9.2.1:
> 

Yes, you're right there.  I'll rewrite that section and send it in
another message.

>     call or about the provided service.

There is complexity because we don't really care whether a URN is
added to an existing Alert-Info or whether a new Alert-Info is
inserted containing the URN.  I looked up the terminology in RFC 3261,
and it isn't quite what I thought it was:

      Header Field: A header field is a component of the SIP message
         header.  A header field can appear as one or more header field
         rows. Header field rows consist of a header field name and zero
         or more header field values. Multiple header field values on a
         given header field row are separated by commas. Some header
         fields can only have a single header field value, and as a
         result, always appear as a single header field row.

      Header Field Value: A header field value is a single value; a
         header field consists of zero or more header field values.

(There is no separate definition of "header field row".)

So a "header field value" is (in our case) a single URN, a "header
field row" is one of those things starting with "Alert-Info:"
containing one or more URNs, and the Alert-Info "header field" is the
abstract array of all of all the URNs.

Also, it seems to be understood that a proxy can reorganize how a
header field is split into header field rows, and can reorder how the
header field rows for one field name are ordered with respect to the
header field rows of another field name.  (RFC 3261 section 7.3 and
section 16.6 step "copy request") But this is not stated very clearly.

Based on that, the first sentences you've listed under section 10 and
section 11 are correct, in that we mean that the UA or proxy can add
URNs as header field values into the array of header field values, and
we don't care how the entity organizes the Alert-Info header field
rows as long as the header field is correct.  I think it would be
clearer to start the sentences:

     A SIP UA/proxy MAY add one or more URN header field values to the
     Alert-Info header field ...

Do we want to footnote "header field" with "RFC 3261 section 6", which
contains the definitions I have quoted?

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 7 Jan 2014 15:32:34 -0500 (EST)

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

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

   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

      Signal 2:  internal

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

      Signal 1:  external

   to Signal 2 "internal".

9.2.2.  Example 2

   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

      Signal 3:  internal
      Signal 8:  internal high

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

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

      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

      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

      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

      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

      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

   Signal 1

      Meaning: default
      Locations:
      - priority

   Signal 2

      Meaning: low
      Locations:
      - priority:low

   Signal 3

      Meaning: high
      Locations:
      - priority:high

      Signal 2:  low
      Signal 1:  default

   Excluded:

      Signal 3:  high

   and Signal 2 "low" is chosen.

   "high" is chosen.

      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

---

From: Laura Liess <[email-masked]>
Date: Thu, 16 Jan 2014 14:01:09 +0100

Dale,

Please see in-line.

>         MM-DD with the publication date of this RFC.]

I agree and changed the draft accordingly.

> contains the definitions I have quoted?

I think the text proposed by Paul is clear enough and I would not insert
any additional explanations.

Thank you
Laura

---

From: Laura Liess <[email-masked]>
Date: Thu, 16 Jan 2014 15:58:50 +0100

Dale,

I changed the draft as you propose.

Thank you
Laura

2014/1/7 Dale R. Worley <[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 17 Jan 2014 15:41:06 -0500 (EST)

In Laura's message of 6 Jan, she gives a revision of the examples, but
the -10 version uses a more detailed revision I provided a few days
later.  However, Laura's version includes this further explanation at
the end of example 4 (9.2.4):

This is a useful observation, and it didn't make it into -10.  All -10
has is "So the Signal 3 "internal" is chosen.", which comes from my
version.  I suggest replacing this sentence with Laura's paragraph.

Dale

---

From: Laura Liess <[email-masked]>
Date: Mon, 20 Jan 2014 10:18:53 +0100

Dale,
This was your old text. I will incorporate it
again in the -11.

Thank you
Laura

2014/1/17 Dale R. Worley <[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 23 Jan 2014 20:29:16 -0500 (EST)

> >    have been chosen, because <urn:alert:priority:low> would have been

Looking at this again, it may be desirable to put a paragraph-break
after the first sentence.

Dale

---

From: Laura Liess <[email-masked]>
Date: Fri, 24 Jan 2014 09:44:15 +0100

Dale,

To comply with one of your earlier comments I would add "internal" after
"Signal 3" and  "external" after "Signal 2". So the text is:

*****
So we choose the Signal 3 "internal".

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 "external" would have been chosen, because
<urn:alert:priority:low> would have been  given precedence.
*******

OK for you?
Thank you
Laura

2014/1/24 Dale R. Worley <[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 28 Jan 2014 16:17:34 -0500 (EST)

> From: Laura Liess <[email-masked]>

> <urn:alert:priority:low> would have been  given precedence.

That looks good to me.

Dale