Subject: [Sipping] WGLC comments on draft-ietf-sipping-dialogusage-03

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Sep 2006 21:18:06 -0400

I went through the whole -03 version this afternoon. We are down to nit 
picking time, so I have a bunch of stuff, but it largely only affects 
form, not the message. This is an important draft and the meat is the 
right meat.

	Thanks,
	Paul

Section 1:

The label for Figure 1 is really hard to see in the position it ended 
up. (Same is true for Figure 2.) I think it is because it is placed 
after the message detail. I think it would be better right after the 
flow diagram.

The second paragraph includes: "Multiple REFERs within a dialog create 
multiple subscriptions, each of which is a new dialog usage sharing 
common dialog state."

While this is true, it might be confusing. After sending a REFER, it 
would not be normal to send another until the first either succeeds or 
fails. Upon either success or failure, it would be normal for the refer 
subscribe usage to terminate as well. So in a normal case I think you 
would not normally have multiple *concurrent* refer subscribe usages. It 
would be possible (for instance the first usage might not end when the 
REFER succeeds) but that would be "weird".

Since the point here in the introduction is simply to motivate multiple 
usages, maybe some other more plausible example would be less confusing. 
An example might be: A invites B, B subscribes to KPML of A, B sends 
REFER to A. This results in an INVITE usage and two subscribe usages in 
different directions for different events. Another could be: A invites 
B, B subscribes to KPML of A, A subscribes to KPML of B. I'm pretty sure 
I know both of these have been implemented, so I guess they are plausible.

Also in section 1: "Usages have state that is not shared in the dialog. 
  For example, a subscription has a duration.  Multiple subscriptions in 
the same dialog each have their own duration."

This is again true, but possibly misleading by omission, in that a 
subscription usage has other state. In addition to duration it has: 
event type, event id, and a direction. I think either this should be 
mentioned, or to avoid that complexity it might be ok to say: "For 
example a subscription has, among other things, a duration."

Section 2.2:

para 1 nit: s/For space,/To focus on the essential points,/

para 2 nit: s/decides skip/decides to skip/

In figure 2 I question the termination point for usage 1. Based on the 
content of section 3.2 it will end on the 200 response to the NOFIFY 
following F3 rather than on the 200 of the unsubscribe.

Section 3.2:

Says that a usage is created by 2xx response to SUBSCRIBE, as well as 
NOTIFY. I think there is some debate whether the 200 actually does 
create a usage, or if it is only the NOTIFY that does so.

Says terminated by 2xx response to NOTIFY-terminated. As noted before 
this contradicts the termination of usage 1 in figure 2. (Question: is 
it also terminated if a NOTIFY is not received reporting the expiration 
of the subscription? If so, when? If too soon then the final NOTIFY will 
not be processed.)

Section 4.1:

I think this section could be drastically shortened, simplified, and 
made easier to comprehend by removing the redundancy. The vast majority 
of the responses are treated the same as 400 - they affect only the 
request and don't change status of usage or dialog except by changing 
the CSeq. But this is said in many different ways. For the most part 
there are only three outcomes:
- impacts only transaction, not usage or dialog
- terminates usage, not dialog
- terminates dialog and all usages
Over and above that, there are some nuances that are worth bringing out 
for some particular responses.

I think this might be handled most concisely by a table with a row for 
each response. It would indicate which of the the three general 
treatments apply to it, with an indication if there are special 
considerations for that one. Then there can be additional text, 
following the table, for each one that has some special considerations 
to note.

In discussion of 400: s/complaint/compliant/

In discussion of 403: This means it is impossible to explicitly request 
termination of the subscription. If the goal was to announce termination 
of the subscription, what should be done? I think the best that is 
possible is for the UAC to declare the usage ended, while the UAS will 
not know it is ended until it attempts to send something else in the 
usage and receives a 481 response.

Discussion of 483 says "the the agent should attempt to gracefully 
terminate this usage and all other usages that share its dialog." It is 
not clear from this language if that means additional signaling should 
be attempted to achieve this graceful termination, or whether only local 
actions should be taken. Remote actions don't seem useful in this case. 
Would be good to be explicit about it. Perhaps say something like:
"the agent should terminate this and all other usages as gracefully as 
is possible without sending further messages in the dialog." Whatever 
the final language is, it applies to several responses.

Discussion of 500: here talks about attempting to gracefully terminate a 
usage or treat it as terminated. Not clear what the difference between 
these is. Similar to comment about 483.

Section 4.4: It might be worth noting that it is problematic to send a 
message for a different usage between the time the target refresh 
request is sent and the time a final response to it is sent or received. 
During this period its impossible to know which target is active at the 
other end. (Of course this applies to requests within a usage too, but 
people might not of considered it in this context.) I would say that 
this should be left to the race-conditions draft, but its trying to 
avoid dealing with multiple usages.

Section 5:

    When designing new applications that use SIP dialogs, do not
    construct multiple usages.  If a peer attempts to create a second
    usage inside a dialog, refuse it.

I think there can be some ambiguity in what is meant by the term "new 
application". When I first read this, I was thinking it meant "a new 
implementation of a UA". So I thought you were suggesting that new 
implementations of a UA, when implementing transfer, should refuse to 
support multiple usages. This is an excellent way to create interop 
problems.

After thinking about it I decided you couldn't possibly mean that, and 
that you must be talking about designing new features for which there 
are no existing implementations. In that case I agree it is fine to 
avoid using multiple dialog usages. Right this second I don't have any 
wording in mind that gets the point across without being too verbose, 
but I am certain it must be possible.

     When designing a new feature that will require new implementation
     by all participating UAs, avoid usage of multiple dialogs.

I still struggle with the part about refusing attempts to create a 
second usage because I am not certain that you can always know whether 
the peer is trying to carry out the new feature, or an old feature in 
the same context. I'm sure it is possible to construct some more 
specific guidelines, but I think it will take some work to get them right.

Section 5:

The paragraph before the call flow says: "A new header, Target-Dialog: 
perhaps". The "perhaps" seems wrong here. Maybe it was included before 
the RFC 4538 was complete. Now there probably should be a reference to 
that RFC.

In the message detail for figure 3, the stuff for gruu is not consistent 
with the latest draft. Minimally the gruu URIs should have a "gruu" uri 
parameter, and the "Supported:gruu" can then be omitted. (That is 
probably sufficient for this example.)

The paragraph:

    Message F2 lets Alice know that Bob understands GRUUs.  If Bob did
    not indicate this support, the original multi-usage approach to
    transfer would have to be used.

is now not quite right either. Neither Alice nor Carol need to know that 
bob understands gruus for this scenario to work. Its bob that needs to 
know Alice and Carol support gruu. Bob learns that from the gruu 
parameter in the Contacts in messages F1 and F4. If alice doesn't 
support then the R-URI for the REFER should be Alice's AOR, and if carol 
doesn't support then the Refer-To should be carol's AOR.

Of course this may change as a result of the WGLC on gruu.

(I was going to try to provide replacement text for this, but I can't do 
it piecemeal. It needs a bunch of small changes distributed through it. 
I can attempt the whole thing if you want.

Section 6 - Security Considerations:

I find the warnings in the first paragraph to be excessively dire. I see 
two kinds of exploits by an "evil doer":

- MiTM attack. If the bad guy can get into a position to inject messages 
into the dialog, then it can attack multiple usages rather than just 
one. But if it could get into one dialog, why not another? This seems to 
be a matter of only doing something quickly before the bad guy can crack 
your security. It could be quick with one usage or several. So I don't 
see the significance of this exploit as something special to multiple 
usages.

- At the UAC or UAS, there might be some kind of multiplexer that 
combines usages into a single dialog. If the code implementing the 
various usages is otherwise independent and untrusting of the code 
implementing the other usages, then there is a threat that malice or 
incompetence in an application implementing one usage could screw up a 
different usage. But that isn't really a fault against multiple usages, 
it is the fault of multiple usages in differing trust domains. This is a 
kind of implementation scope that isn't often addressed in the sip 
specifications, so I don't know why it would be addressed here. But if 
it is, I think the scope should be suitably narrowed. I expect that the 
more common case is that all the usages are implemented within the same 
"application".

_______________________________________________
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