Rohan, OK, I can accept the explanations you give.
John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Rohan Mahy > Sent: 06 April 2008 18:41 > To: Elwell, John > Cc: IETF SIP List; Rohan Mahy; Francois Audet; Cullen Jennings > Subject: Re: [Sip] Review of sip-outbound-13 > > 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 > _______________________________________________ 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
