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

From: [email-masked]
Date: Thu, 19 May 2005 10:50:53 EDT

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".

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.

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.

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.

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 29 May 2005 17:16:52 -0500

comments below

At 10:50 AM 5/19/2005 -0400, [email-masked] wrote:
>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.

>"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.

>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.

>"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.
>

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.

>Artel, Inc.

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