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

[Laura Liess <[e-mail]>]

Paul,

Thank you for the comments. Please see inline.

2013/11/21 Paul Kyzivat <[e-mail]>

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