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. For 7, it should say "A configuration option indicating...". For 9, I'll have to defer to Rohan and Cullen because I find it confusing too. 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. > -----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
