> -----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?
> > For 7, it should say "A configuration option indicating...". [JRE] OK, on re-reading it I understand it better, since it is referring to the "explicit indication" in the previous paragraph. However, I think your proposed wording change would be be an improvement. > > 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. > > 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? John > > > > > -----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
