Subject: Review of Section 2.12. Single Line Extension (was RE: [Sipping] WGLC of draft-ietf-sipping-service-examples-10.txt)

From: "Burger, Eric" <[email-masked]>
Date: Tue, 13 Jun 2006 05:01:12 -0400

For the most part, the section is clear and correct.  With the exception
of a major concern about presenting an interoperable call flow,
everything is editorial.  I found no substantial protocols errors.

Main Concern
------------
[See 2nd paragraph of Page 107]
My main concern, and one which may spill into other service examples, is
the example is NOT INTEROPERABLE.  This service example is not
interoperable because it makes service assumptions that cannot be made
in a multi-vendor environment.  For example, the single line extension
service example says, "To avoid this scaling issue, this flow uses an
implicit subscription between each of the group members and a simple
forking proxy."  While this is nice and saves on subscription requests,
there is no way for the devices to KNOW they will get unsolicited
subscriptions.

Using the example from the text, there is no way for B1, B2, and B3 to
know about the implicit registration package subscription and there is
no way for B1 and B2 to know about the implicit dialog package
subscription.  Conversely, B1, B2, and B3 may rely on the proxy
implicitly registering them for the registration package, and the proxy,
following every line of RFC 3261,2,3,4,5, etc., does not implicitly
register them.  There is a similar argument for the dialog package
registration.

I would suggest either:
   (1) Put in explicit subscriptions.  Mention in passing
       that one could create a system with devices that use
       implicit subscriptions if they know the proxy server
       will impose implicit subscriptions on them anyway.
   (2) Keep the call flows as is, but put in a big, bold
       Notice that the call flow is NOT interoperable.

My personal preference is (1) for an IETF publication.  Otherwise, you
can bet some implementers will point to this draft and say, "All User
Agents MUST accept dialog package notifications, whether they subscribe
or not."

Clarification on Operation
--------------------------
[Third paragraph of Page 107, fifth line]
The call flow does the correct thing and shows all of the user agents
receiving the notification.  I would suggest changing the text from:

"B3 sends a NOTIFY containing the dialog information to the AOR for Bob,
which is forked to B1 and B2.  (The service-unaware forking proxy
actually forks it back to B3 as well, but B3 simply discards with a 482
Loop Detected response.)"

To

"B3 sends a NOTIFY containing the dialog information to the AOR for Bob.
Since the proxy is not aware of the service semantics, the proxy forks
the notification to all of Bob's registered user agents B1, B2, and B3.
B3 simply discards the notification with a 482 Loop Detected response."

Nit
---
Page 108, 4th full paragraph, 1st line:
OLD
The use of SUBSCRIBE and NOTIFY is defined in [6] while
NEW
The use of SUBSCRIBE and NOTIFY is defined in [6], while
                                                 ^

Message F11
-----------
Message F11 (Page 112) is from the Proxy to Alice, not from B3 to the
Proxy.
OLD
F11 180 Ringing B3 -> Proxy
NEW
F11 180 Ringing Proxy -> Alice

Gonzalo Camarillo wrote:
> Folks,
> 
> we would like to working group last call (WGLC) the following draft:
> 
>
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-
10.txt
> 
> 
> 
> as you have probably noticed if you clicked on the link above, this
> is a very long draft. Therefore, we would like to get at least ten
> volunteers to review it. We will assign a couple of sections to each
> reviewer.
> 
> If you are interested and willing to review this draft, please send
> an email to the SIPPING chairs.
> 
> The email below should be considered as a WGLC comment:
> 
> http://www1.ietf.org/mail-archive/web/sipping/current/msg10886.html
> 
> This is the output of the idnits tool:
> 
> idnits 1.96
> 
> tmp/draft-ietf-sipping-service-examples-10.txt:
> 
> 
> Checking nits according to http://www.ietf.org/ID-Checklist.html:
> 
> Checking conformance with RFC 3978/3979 boilerplate...
> 
> the boilerplate looks good.
> 
> * There is 1 instance of too long lines in the document, the longest
> one being 1 character in excess of 72.
> 
> Checking nits according to
> http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but
> these checks do not cover all of 1id-guidelines.txt yet).
> 
> Miscellaneous warnings: - Line 1028 has weird spacing: '... /* Bob
> place...' - Line 1404 has weird spacing: '... /* Bob  takes...' -
> Line 1732 has weird spacing: '... /* Bob  place...' - Line 2459 has
> weird spacing: '...and Bob  have ...' - Line 2597 has weird spacing:
> '... /* Bob  puts ...' - (4 more instances...)
> 
> Experimental warnings: - Unused Reference: [18] is defined on line
> 7860, but not referenced - Unused Reference: [13] is defined on line
> 7839, but not referenced - Unused Reference: [14] is defined on line
> 7842, but not referenced - Unused Reference: [1] is defined on line
> 7795, but not referenced
> 
> 
> 
> 
> This WGLC will end on July 1st, 2006 (a long draft needs a long
> WGLC).
> 
> Thanks,
> 
> Gonzalo SIPPING 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

_______________________________________________
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