Subject: RE: [Sipping] WGLC for draft-ietf-sipping-reason-header-for-preemption-00.txt

From: "Eric Burger" <[email-masked]>
Date: Sat, 6 Mar 2004 18:51:24 -0500

I agree with Mike on the need for a third reason code.  Other than that, IMHO the protocol is baked.

Other comments:

There are a couple of sections of the document that are informative, but have RFC2119 language.  They are:
1. Section 2.0, the paragraph after Figure 1
The paragraph says that in the example, UA2 MUST preempt all calls.  That might be its local policy, but that is not a protocol issue.  Thus MUST must be must :-)

2. Section 2.1: same logic for the last sentence.  MUST must be must.

3. Section 4.1.1: same logic for the second to last paragraph (UA2 again)

In section 6, this document will define, not propose the new SIP reason header.  Also, there is a curly-brace after XXXX.

In the abstract, should the last sentence have a comma instead of a semi-colon?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 01, 2004 7:45 AM
To: [email-masked]; [email-masked]
Subject: Re: [Sipping] WGLC for draft-ietf-sipping-reason-header-for-preemption-00.txt

In a message dated 3/1/2004 1:38:29 PM Korea Standard Time, [email-masked] writes: 

>[MAP] The requirment for Assured Service (otherwise known as MLPP) is that the 
>preempted party is not allowed to know why the preemption occurred. This 
>would have the result of telling the person 

[JP] how exactly is informing the UA translate into telling the user why 
something has happened always (which is the way I read your question)? 

I always make the assumption that anything sent to the UA (the physical telephone) may be displayed to the user (human). If the service requires that the user (human) can't see some data that might be in a SIP messages (e.g., location, ID of the other party) then that data can't be included in the messages with an expectation that every device will keep it secret. The same is true of the reason for preemption (access or network preemption). 

Mike Pierce 

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

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 9 Mar 2004 10:44:17 -0500

I could go either way.

Pro for Q.850 as "protocol": it is already there; if someone has a UA implementation that understands Reason, it will just work.

Con for Q.850 as "protocol": it isn't the protocol being used.  Are there other protocol semantics / expectations when Q.850 shows up in the Reason code?  Will someone call customer care and say, "But I wasn't making an ISDN call -- it was all SIP-SIP?"

Also, reuse is not a real value here.  If a UA will understand cause=1 and cause=2, they can just as easily understand cause=3.

That said, I personally do not have a stake in either way of stating network preemption.

> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, March 09, 2004 8:58 AM
> To: Eric Burger; [email-masked]
> Subject: RE: [Sipping] WGLC for
> draft-ietf-sipping-reason-header-for-preemption-00.txt
> 
> 
> At 06:51 PM 3/6/2004 -0500, Eric Burger wrote:
> >I agree with Mike on the need for a third reason code.  
> Other than that, 
> >IMHO the protocol is baked.
> 
> Eric - talked with Mike and others in Seoul about this issue. 
> I suggested 
> the following:
> 
>          Reason: Q.850; cause=8; "preemption"
> 
> for a generic preemption indication (Q.850 is already defined 
> in 3326, but 
> offers no further applicable granularity). Mike (and others) 
> stated they 
> agree this will serve the purpose for a generic preemption 
> indication. Will 
> this do for your reasoning as well, or do we want a non-850 
> indication as well?
[snip]

---

From: [email-masked]
Date: Thu, 11 Mar 2004 05:31:33 EST

In a message dated 3/9/2004 10:42:41 AM Eastern Standard Time, 
[email-masked] writes:

> >The paragraph says that in the example, UA2 MUST preempt all calls.  That 
> >might be its local policy, but that is not a protocol issue.  Thus MUST 
> >must be must :-)
> >
> no problem with the above 3 changes
> 

I disagree with this. RFC 2119 defines what the word "must" means. It makes 
no distinction between an upper case "MUST" and a lower case "must", although 
it notes that these keywords are "often capitalized". Changing the word from 
upper case to lower case does not change its meaning. It requires a wording 
change if you want to change the meaning. Since the referenced text in 2.0 is an 
"example" and refers to "local policy" already, it could read simply "Local 
policy within this domain dictates if UA2 preempts all existing calls ...".

In 2.1, since the first part of the paragraph says "if a UA must preempt 
...", the final "MUST" is not a problem. However, it could be changed to simply 
read "then a BYE is sent ..."

In 4.1.1, same as in 2.0.

Mike Pierce

---

From: [email-masked]
Date: Thu, 11 Mar 2004 11:42:18 EST

In a message dated 3/9/2004 10:53:46 AM Eastern Standard Time, 
[email-masked] writes:

> Con for Q.850 as "protocol": it isn't the protocol being used.  Are there 
> other protocol semantics / expectations when Q.850 shows up in the Reason 
> code?  Will someone call customer care and say, "But I wasn't making an ISDN call 
> -- it was all SIP-SIP?"
> 

My agreement to depend on use of the Q.850 error code instead of either of 
the new "reasons" defined in this new draft presumes that such a use of a Q.850 
error code within SIP is considered to be completely "normal" and that SIP 
devices are required to understand it. Do your think that this is true? This 
would perpetuate the use of Q.850 error codes long after everything is completely 
SIP.

Mike Pierce

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 11 Mar 2004 11:44:08 -0500

For that matter, what if Q.850 changes the meaning of code 8?

It is not like we have a dearth of name space...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 11, 2004 11:42 AM
To: Eric Burger; [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] WGLC for draft-ietf-sipping-reason-header-for-preemption-00.txt

In a message dated 3/9/2004 10:53:46 AM Eastern Standard Time, [email-masked] writes: 

My agreement to depend on use of the Q.850 error code instead of either of the new "reasons" defined in this new draft presumes that such a use of a Q.850 error code within SIP is considered to be completely "normal" and that SIP devices are required to understand it. Do your think that this is true? This would perpetuate the use of Q.850 error codes long after everything is completely SIP. 

Mike Pierce

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 15 Mar 2004 08:43:12 -0600

>For that matter, what if Q.850 changes the meaning of code 8?

then 3326 should need to be updated...

>It is not like we have a dearth of name space...

you're killing me here

OK - can I limit the use of this 3rd SIP Preemption cause code to be used 
only where there might be some security issues or misbehaving UA's?

I believe SIP should use the UA and RSVP preemption codes if that's what 
happened (to update the SIP servers), but on the off chance that a UA won't 
understand *not* to display such a difference or might play another special 
tone, the code should be changed at the 2nd to last VIA entity to this 
generic code for the receiving UA to not know anything other than *a* 
preemption event happened.

Opening up a can of worms, should there be another code added for the case 
that the preemption event occurred in a TDM infrastructure that is (from 
local policy) transmitted through to the IP infrastructure for a hybrid 
call? In this case, the UA needs to be informed of the preemption, but that 
it didn't happen within the IP domain - or should this case have the SIP 
Gateway considered a UA, and use that preemption code?

thoughts

>Subject: Re: [Sipping] WGLC for 
>code?  Will someone call customer care and say, "But I wasn't making an 
>ISDN call -- it was all SIP-SIP?"
>
>
>
>the new "reasons" defined in this new draft presumes that such a use of a 
>Q.850 error code within SIP is considered to be completely "normal" and 
>that SIP devices are required to understand it. Do your think that this is 
>true? This would perpetuate the use of Q.850 error codes long after 
>everything is completely SIP.
>
>Mike Pierce

cheers,
James

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Mar 2004 07:57:44 -0600

>IMHO the protocol is baked.

Eric - talked with Mike and others in Seoul about this issue. I suggested 
the following:

for a generic preemption indication (Q.850 is already defined in 3326, but 
offers no further applicable granularity). Mike (and others) stated they 
agree this will serve the purpose for a generic preemption indication. Will 
this do for your reasoning as well, or do we want a non-850 indication as well?

>In section 6, this document will define, not propose the new SIP reason 
>header.

I always leave it as a "propose" until the version after WGLC (a habit). 
Therefore, my next version (to be discussed this week with the SIPPING 
chairs) will change all "proposes" to "defines" (there are actually eight 
"proposes" that need changing).

>Also, there is a curly-brace after XXXX.

thanks for this catch

>In the abstract, should the last sentence have a comma instead of a 

probably

>I always make the assumption that anything sent to the UA (the physical 
>telephone) may be displayed to the user (human). If the service requires 
>that the user (human) can't see some data that might be in a SIP messages 
>(e.g., location, ID of the other party) then that data can't be included 
>in the messages with an expectation that every device will keep it secret. 
>The same is true of the reason for preemption (access or network preemption).
>
>Mike Pierce

cheers,
James

                                *******************