Hi John, Thanks for your detailed comments. I have a few specifics inline.
On Apr 5, 2008, at 11:34 AM, Elwell, John wrote: > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Francois Audet >> Sent: 05 April 2008 00:38 >> To: Elwell, John; IETF SIP List; Cullen Jennings; Rohan Mahy >> Subject: Re: [Sip] Review of sip-outbound-13 >> >> Thank you John. >> >> I am OK with your edits 1, 2, 4, 5, 6, 8 and 11. >> >> I don't understand your point about 3. > [JRE] It says that there is a case where a UA might not want to use > the > sip.instance media feature tag, yet that tag is essential for > outbound. > Is it saying that in such a case the UA should not use sip-outbound? The text is explaining under what circumstances a UA would decide not to include +sip.instance in (any kind of) request. Outbound registration requests certainly will not work if the UA leaves this parameter out. I believe some of this is discussed in GRUU, but a complete discussion of this topic is certainly out of scope of the outbound spec. [snip] >> For 9, I'll have to defer to Rohan and Cullen because I find it >> confusing too. > [JRE]Yes, and that is why I wasn't able to propose new words. We provided SHOULD level recommendations for the timers in this section. If the UA has a good reason to do something else it MAY. The timers, the random spacing or lack thereof, even the backoff algorithm, they all could be configurable. This is all we can say and all we should say on the matter. I don't want to clutter up the text with a lot of text explaining things that UAs could do that we don't recommend. I am certainly open to reading new proposed text, but I think the current text tells implementors what they should do pretty clearly. >> For 10, I believe that it would work if an upstream evil B2BUA does >> topology hiding since the proxy uses the Via in the Request >> and not the >> Path in the response. > [JRE] What I meant was, if a proxy receives a REGISTER request with > only > a single element in the Via header field, how does it know whether the > request came from a UA or from a topology-hiding B2BUA? This is > probably > an unlikely situation for a REGISTER request (UA -> B2BUA -> > proxy), but > can we rule it out? A B2BUA has to behave as a legal UA. The B2BUA will either advertise support for the outbound option-tag or not. If it does not support outbound, the registrar won't try an outbound-style registration and the original UAC will discover that from the response (no problem). If the B2BUA wants to support outbound, it will need to follow the spec. If the B2BUA wants to simulate an outbound-aware edge proxy, and also support topology hiding, it will need to insure that there are at least two Via headers in the request. It could easily do this by adding itself twice to the Via header field (possible, but not our problem). Even if the B2BUA is truly broken and blindly copies option tags from the original UAC to the registrar (DON"T DO THIS KIDS!!!), it is unlikely that the B2BUA will know about and insert the 'ob' parameter in the first Path header. The next hop will think the first edge proxy did not support outbound and carry on with non-outbound registration. thanks, -rohan >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>> Behalf Of Elwell, John >>> Sent: Friday, April 04, 2008 07:01 >>> To: IETF SIP List >>> Subject: [Sip] Review of sip-outbound-13 >>> >>> I think this is ready to go if the following minor comments are >>> addressed: >>> >>> 1. "This >>> specification also defines multiple keep alive schemes." >>> Change "multiple" to "two". >>> >>> 2. "A Flow is a network protocol layer (layer 4) association" >>> Change "network" to "transport". >>> >>> 3. "One case where a UA may not want to include >>> the sip.instance media feature tag at all is when it is making an >>> anonymous request or some other privacy concern requires >>> that the UA >>> not reveal its identity." >>> There is no statement about what should be done in this case. >>> >>> 4. "These registration requests include a distinct reg-id >> parameter in >>> the Contact header field." >>> I think some normative language is needed here. Perhaps change to: >>> "For registration requests in accordance with outbound >>> behaviour, the UA MUST include a distinct reg-id parameter in >>> the Contact header field." >>> >>> 5. "the target first >>> hop SIP note" >>> Change "note" to "node". >>> >>> 6. "as this is already allowed by >>> [RFC3261]. Section 7.5, however a UA that did not register using >>> outbound registration" >>> I think this should say >>> "as this is already allowed by >>> [RFC3261] section 7.5. However, a UA that did not register using >>> outbound registration" >>> >>> 7. "Configuration indicating keepalive support for a specific >>> target is >>> considered an explicit indication. If these conditions are >>> satisfied, the UA sends its keepalives according to the same >>> guidelines described in the rest of this section as UAs which >>> register." >>> I don't understand the meaning of the first sentence. Is it >>> trying to say that configuration is an alternative way of >>> determining support for keepalive? >>> >>> 8. "For devices where power is >>> not a significant concern, the UA SHOULD select a random number >>> between 95 and 120 seconds between keepalives. When >>> battery power is >>> a concern, the UA SHOULD select a random number between >> 672 and 840 >>> seconds (14 minutes). These times MAY be configurable." >>> The last sentence seems to undermine the previous SHOULD >>> strength statements. Also, what exactly can be configurable - >>> just the upper and lower bounds? I don't think, for example, >>> we are proposing to allow somebody to configure say 180 >>> seconds as both upper and lower bounds (not a range, no >>> randomisation). So I think it is the bounds that can be >>> configurable, and even then the 20% difference must be maintained. >>> Perhaps it should say something like: >>> "The UA MUST select a random number between a fixed or >>> configurable upper bound and a lower bound, where the lower >>> bound is 20% less then the upper bound. The fixed upper bound >>> or the default configurable upper bound SHOULD be 120 seconds >>> (95 seconds lower bound) where battery power is not a concern >>> and 840 seconds (672 seconds lower bound) where battery power >>> is a concern." >>> >>> 9. "The delay time is computed by selecting a uniform random >>> time between >>> 50 and 100 percent of the wait time. The UA MUST wait for >>> the value >>> of the delay time before trying another registration to >> form a new >>> flow for that URI." >>> I find this a little confusing. The several paragraphs before >>> that have all talked about wait time, or time to wait, which >>> suggests that that is how long you wait before trying >>> registration again. Then we suddenly have this "delay time" >>> introduced, and it says that "UA MUST wait for the value of >>> the delay time before trying another registration". It might >>> be better to introduce the concept of delay time and wait >>> time up front. Furthermore, it is not clear whether the delay >>> time (between 50 and 100 percent of the wait time) starts >>> when the wait time starts or when the wait time finishes. I >>> think the examples given in the succeeding paragraph suggest >>> it is the former interpretation. In any case, it needs to be >>> clarified. >>> >>> 10. "The Edge Proxy can determine >>> if it is the first hop by examining the Via header field." >>> Does this still work in the case of topology hiding by an >>> upstream entity? >>> >>> 11. "When a '+sip.instance' media feature parameter is present in a >>> Contact header field of a REGISTER request (after the >>> Contact header >>> validation as described above), the corresponding binding >>> is between >>> an AOR and the combination of the instance-id (from the >>> +sip.instance >>> media feature parameter) and the value of reg-id >> parameter if it is >>> present." >>> I think the normative statements that follow are only >>> concerned with the case where reg-id is present, so I think >>> it should be changed to: >>> "When a '+sip.instance' media feature parameter and a reg-id >>> parameter are present in a >>> Contact header field of a REGISTER request (after the >>> Contact header >>> validation as described above), the corresponding binding >>> is between >>> an AOR and the combination of the instance-id (from the >>> +sip.instance >>> media feature parameter) and the value of reg-id parameter." >>> >>> John >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> [EMAIL PROTECTED] for questions on current sip >>> Use [EMAIL PROTECTED] for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use [EMAIL PROTECTED] for questions on current sip >> Use [EMAIL PROTECTED] for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
