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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip