Subject: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt

From: "Mary Barnes" <[email-masked]>
Date: Mon, 11 Sep 2006 11:19:40 -0500

Hi all,

This is to announce Working Group Last Call on the following draft
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-03.tx
t

We alredy have 3 volunteer reviewers assigned (Paul Kyzivat, Derek
MacDonald and Vijay Gurbani), but additional volunteers are also
welcome:
http://www.softarmor.com/sipping/process/wg-review/sipping-rt.html

The spreadsheet will be updated shortly to reflect the state of this
document in WGLC. 

As always, anyone else that gets a chance to review should also send
their feedback to the authors and copy the SIPPING mailing list. 

This WGLC will end on Oct 2nd, 2006 (three weeks time). 

Thanks, 
Mary 
SIPPING WG co-chair

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Fri, 15 Sep 2006 13:30:37 -0500

I do have some high-level comments on this draft.

I don't want to spoil the party, but I don't think we are
doing the right thing with dialogusage.

The draft does an excellent job of explaining the complexities
introduced by sharing the same dialog for different usages.

However, I think it will completely baffle people as it really 
doesn't offer any way out of the mess. The conclusion pretty
much says "it's a mess, we don't know how to get out of it",
and offers some vague hope that one day GRUU combined with not
using shared dialogs will solve the problem.

I'm quite worried that instead of helping, this would actually
be even more confusing for people. I'm also not that convinced
that it is realistic to think that we will be able to migrate
to a nirvana where dialogs are not shared.

So to me, the material in the draft should really be a call to action
for us to fix the problems, not just describe that all hope is lost.

Now, for specifics.

The part that bothers me the most is section 4.1 describing different
behaviors for 7-pages worth of error codes.

It seems to me insanely complicated, and furthermore, it seems
unrealistic
to me to expect that implementations will follow all those rules. 

I really think we need to come up with a generic rule for error response
codes,
as as little "exceptions" as possible. We really should be very careful
before
allowing exceptions. Many of the exceptions listed in there may
theoretically
make sense, at some intellectual level, but it is not clear at all that
they
offer any practical value.

It is also not always clear what methods the error are
applicable to. For example, the entry for "400 and unrecognized" seems
to apply
only to NOTIFY, but 403 also talks about re-INVITE (what about re-INVITE
and 400?).

For example, let's say that we decided that 4XX response (unless
otherwise noted)
would only apply to the transaction (re-INVITE, NOTIFY, etc.). Before we
make exceptions for all possible error codes, we should really make sure
it
has benefits. To take a specific example: 404. Why not just apply the
same rule
here? i.e., that it would apply to the transaction only instead of
tearing down
the whole thing as per the current wording.

The draft makes a very good job explaining why certain error codes used
in
an existing dialog makes no sense, but the conclusion that if they are
received
"something must have gone horribly wrong and we should tear down the
whole thing"
seems like overly harsh. I think it will be extremely vulnerable to
non-perfect
implementations. I'd much rather have a simple rule (i.e., "applies to
the transaction")
than to try to assign too many complicated rules to individual error
codes.

My 2 cents....

> -----Original Message-----
> From: Barnes, Mary (RICH2:B601) 
> Sent: Monday, September 11, 2006 9:20 AM
> To: [email-masked]
> Subject: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt
> 
> Hi all,
> 
> We alredy have 3 volunteer reviewers assigned (Paul Kyzivat, 
> Derek MacDonald and Vijay Gurbani), but additional volunteers are also
> welcome:
> The spreadsheet will be updated shortly to reflect the state 
> of this document in WGLC. 
> 
> As always, anyone else that gets a chance to review should 
> also send their feedback to the authors and copy the SIPPING 
> mailing list. 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2006 15:35:45 -0400

> for us to fix the problems, not just describe that all hope is lost.

I guess I have just gotten used to ignoring the tone of the draft in 
that regard. But I don't agree with the tone.

We seem to think we dealt ourself a lemon in 3261 with the dialog 
sharing. I agree to the extent that I think life would have been simpler 
without it. But since the lemon is there I think we can make some pretty 
good lemonade with it. I seem to be the only person that thinks we 
should exploit the capability since we are stuck with it anyway.

I don't believe the problems are nearly as dire as some make them out to 
be. And the draft really shows that by spelling out the correct 
behaviors. Once you follow those things aren't particularly bad.

IMO you can approach this capability in two ways:

- you can try to identify the few particular applications of it
   that you believe have been sanctioned, and attempt to implement
   those as special cases.

- you can build support for the general mechanism. It will then
   support the sanctioned cases, but will also support lots of
   other potential usages that fit the same general model.
   Having done so, you can use the mechanism when it suits a
   need.

In my experience the first approach is likely to lead to lots of bugs 
and interoperability problems as people make assumptions about how the 
special cases operate. It also may result in special code for each case 
that has an opportunity to be buggy.

The second approach is likely to be easier to implement, rather than 
harder. And likely to be no more code - maybe less. And less prone to be 
buggy because it isn't full of special cases.

I think there are a few things that require small revisions to 3261 (and 
maybe some other RFCs) to resolve ambiguities, etc. I don't think there 
are any big "fixes" that are required.

That doesn't mean that shared dialog usages are good for everything. 
There are clearly cases where the coupling between the usages can cause 
a lot of grief. The answer there is clearly "if it hurts, don't do it". 
And a document like this can go a long way to help people identify the 
cases where it will hurt.

So far I haven't found anybody else with this opinion. Everybody else 
seems to be on the other side - that these things are evil. So I have 
giving up arguing about it. Until now.

> as as little "exceptions" as possible.

This is pretty much in line with the comments I made the other day. I 
don't think it is necessary to change the recommendations at all. But I 
think the material can be organized in a much more concise way.

> We really should be very careful
> before

I thought about this too - about whether a table indicating handling 
should be indexed by method as well as response code.

If so, we would end up with something like 3261 Table 2, and we know how 
popular that is.

I finally concluded that in most cases the actions work regardless of 
method. Enough so that the exceptions can simply be dealt with a such.

> the whole thing as per the current wording.

 From what I could see there are only about three different actions. So 
all that is needed is to specify which response gets which action. As 
best I can tell the actions called out now are the appropriate ones.

> than to try to assign too many complicated rules to individual error

The cases that are called out as horribly wrong really are. I agree with 
the recommended treatments in that case.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2006 15:35:45 -0400

Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 15 Sep 2006 16:36:44 -0500

Thanks Paul. I guess I agree with pretty much everything you wrote in
there.

Except for the very last sentence:

	The cases that are called out as horribly wrong really are. I
agree with the recommended 
	treatments in that case. 

Almost all of those cases seem to not be as horribly wrong as stated.

For example:

416: I send a re-invite with sips (on a dialog that was established with
sip). With the current
     wording, this would kill the "dialog and all of it's usage". I do
not think that this is
     warranted at all. To me, it should stay in the previous state
(i.e., sip).

404: I don't see that if a 404 is receive it warrants destroying the
dialog and all usages. I don't 
     see what good it does to do so. Seems to me just considering that
request to be rejected
     is a lot safer.

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, September 15, 2006 12:36 PM
> To: Audet, Francois (SC100:3055)
> Cc: Barnes, Mary (RICH2:B601); [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt
> 
> 
> 
> Francois Audet wrote:
> > I don't want to spoil the party, but I don't think we are doing the 
> > right thing with dialogusage.
> > 
> > However, I think it will completely baffle people as it 
> really doesn't 
> > offer any way out of the mess. The conclusion pretty much 
> says "it's a 
> > mess, we don't know how to get out of it", and offers some 
> vague hope 
> > that one day GRUU combined with not using shared dialogs will solve 
> > the problem.
> > 
> > I'm quite worried that instead of helping, this would 
> actually be even 
> > more confusing for people. I'm also not that convinced that it is 
> > realistic to think that we will be able to migrate to a 
> nirvana where 
> > dialogs are not shared.
> > 
> I guess I have just gotten used to ignoring the tone of the 
> draft in that regard. But I don't agree with the tone.
> 
> We seem to think we dealt ourself a lemon in 3261 with the 
> dialog sharing. I agree to the extent that I think life would 
> have been simpler without it. But since the lemon is there I 
> think we can make some pretty good lemonade with it. I seem 
> to be the only person that thinks we should exploit the 
> capability since we are stuck with it anyway.
> 
> I don't believe the problems are nearly as dire as some make 
> them out to be. And the draft really shows that by spelling 
> out the correct behaviors. Once you follow those things 
> aren't particularly bad.
> 
> In my experience the first approach is likely to lead to lots 
> of bugs and interoperability problems as people make 
> assumptions about how the special cases operate. It also may 
> result in special code for each case that has an opportunity 
> to be buggy.
> 
> The second approach is likely to be easier to implement, 
> rather than harder. And likely to be no more code - maybe 
> less. And less prone to be buggy because it isn't full of 
> special cases.
> 
> I think there are a few things that require small revisions 
> to 3261 (and maybe some other RFCs) to resolve ambiguities, 
> etc. I don't think there are any big "fixes" that are required.
> 
> There are clearly cases where the coupling between the usages 
> can cause a lot of grief. The answer there is clearly "if it 
> hurts, don't do it". 
> And a document like this can go a long way to help people 
> identify the cases where it will hurt.
> 
> So far I haven't found anybody else with this opinion. 
> Everybody else seems to be on the other side - that these 
> things are evil. So I have giving up arguing about it. Until now.
> 
> > Now, for specifics.
> > 
> > unrealistic to me to expect that implementations will 
> follow all those 
> > rules.
> > 
> > I really think we need to come up with a generic rule for error 
> > response codes, as as little "exceptions" as possible.
> 
> This is pretty much in line with the comments I made the 
> other day. I don't think it is necessary to change the 
> recommendations at all. But I think the material can be 
> organized in a much more concise way.
> 
> > theoretically make sense, at some intellectual level, but it is not 
> > clear at all that they offer any practical value.
> > 
> applicable to. 
> > For example, the entry for "400 and unrecognized" seems to 
> apply only 
> > to NOTIFY, but 403 also talks about re-INVITE (what about re-INVITE 
> > and 400?).
> 
> I thought about this too - about whether a table indicating 
> handling should be indexed by method as well as response code.
> 
> If so, we would end up with something like 3261 Table 2, and 
> we know how popular that is.
> 
> I finally concluded that in most cases the actions work 
> regardless of method. Enough so that the exceptions can 
> simply be dealt with a such.
> 
> > otherwise noted) would only apply to the transaction (re-INVITE, 
> > NOTIFY, etc.). Before we make exceptions for all possible 
> error codes, 
> > we should really make sure it has benefits. To take a specific 
> > example: 404. Why not just apply the same rule here? i.e., that it 
> > would apply to the transaction only instead of tearing down 
> the whole 
>  From what I could see there are only about three different 
> actions. So all that is needed is to specify which response 
> gets which action. As best I can tell the actions called out 
> now are the appropriate ones.
> 
> > The draft makes a very good job explaining why certain error codes 
> > used in an existing dialog makes no sense, but the 
> conclusion that if 
> > they are received "something must have gone horribly wrong and we 
> > should tear down the whole thing"
> > non-perfect implementations. I'd much rather have a simple 
> rule (i.e., 
> > "applies to the transaction") than to try to assign too many 
> > complicated rules to individual error codes.
> 
> The cases that are called out as horribly wrong really are. I 
> agree with the recommended treatments in that case.
> 
> 	Paul
> 
> > My 2 cents....
> > 
> > 
> >  
> > 
> also send 
> >> 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
> >>
> > 
> > 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: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2006 18:37:16 -0400

>      warranted at all. To me, it should stay in the previous state

OK, I have to agree with you on that one.

>      see what good it does to do so. Seems to me just considering that

I think destroying all is appropriate in this case. Suppose there was 
only a single usage, and this was a request probing to test liveliness 
of the other end. This is a pretty good reason to believe the session at 
the other end is not functional, so at least the usage should be torn 
down. If there are other usages, then they share the same address, and 
so requests to them will receive the same treatment. (All the usages are 
coupled on this piece of dialog state.) So if it makes sense to tear 
down one usage it makes sense to tear them all down.

I guess the alternate viewpoint is that if there is a problem then the 
error should be 481. But I think it is possible that the 404 error would 
be detected first in some implementations.

	Paul