Re: [Sip] Comments on Last Call of "Extending Reason-header for Preemption Events"

["James M. Polk" <[e-mail]>]

comments below

At 10:50 AM 5/19/2005 -0400, [e-mail] wrote:
>The following comments are submitted on 
>draft-ietf-sipping-reason-header-for-preemption-02.
>
>Section 5
>The second reason listed should be for a general network preemption, no 
>matter what technique is used to cause it. RSVP is only one possible way. 
>The reason should not be named "RSVP".

This is how I originally wrote it (as "network-based"). Early WG consensus 
changed it to "RSVP" as several commented they wanted the granularity of 
more than one type of non-endpoint reason for preemption. In the future, I 
believe there could be one for NSIS, one for security level, etc. Each of 
those will necessitate an extension to this document once the WG agrees 
there is such a need.


>In fact, it appears that the important part of the defined protocol is the 
>cause value (2" for this case) to mean "network preemption". The following 
>"default" text is optional, only used for those cases in which a human 
>user might read this for more information concerning the reasons for 
>preemption. Since it is referred to as "default text", there should be no 
>reason that it could not be anything else an implementation wanted to use. 
>The formal definition of the syntax in RFC 3326 makes the text part 
>optional. However, this draft appears to require that both the cause value 
>and the text are always present and with the exact text string given 
>(mistakenly described in the "IANA Considerations" section.) This needs to 
>be corrected to be consistent with RFC 3326.

The text is default and optional and can be changed within an 
administrative domain to something else. The cause code is what SIP 
elements react to. These is nothing in the document stating anything to do 
with the UI. I left that out on purpose.


>Section 5.2
>This needs to be reworded so it is not RSVP-specific. Any mention of RSVP 
>should only be as an example of how network preemption might be controlled.

If the WG wanted cause=2 to be RSVP Preemption (see above), then I don't 
believe changes are necessary.


>Section 7 IANA Considerations
>As noted above, this section contains an erroneous statement about what 
>"syntax shall be used". At the same time, it is unclear what the IANA 
>registration requirements are. For example, this part implies that IANA 
>needs to register the text strings, when there is clearly no need for that.
>
>Section 10 Normative References
>RFC 2205, RSVP, should not be listed as Normative.

2205 describes premption in RSVP. In order for the reader to know that is 
the case, and how this mechanism is mapped to that mechanism, there needs 
to be a binding. I chose normative based on the desire of the WG to have 
cause=2 to be RSVP Preemption. With this in mind, I don't believe changes 
are necessary.


>Mike Pierce
>Artel, Inc.
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [e-mail] for questions on current sip
>Use [e-mail] for new developments on the application of sip


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

                      Alas, few *truths* exist without the math.

                             ...all else is a matter of perspective

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip