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

[Paul Kyzivat <[e-mail]>]

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