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
