[sipcore] AD review: draft-ietf-sipcore-keep-08

[Robert Sparks <[e-mail]>]

Summary: Revised ID needed

The text needs to be adjusted to reflect the security issue I called out in a separate message to the list today.
During that adjustment, there are a few other places to consider making changes:

* Section 4.4, second paragraph "The parameter can contain" is confusing - it could be read to imply that
the parameter can contain other things as well. I suggest rewriting this sentence as "The parameter value,
if present, represents a recommended keep-alive frequency..."

* The document talks about invoking keep for INVITE initiated dialogs, but not about SUBSCRIBE initiated
   dialogs. Was it the intent to not allow the use of the mechanism for SUBSCRIBE initiated dialogs?
   
* Section 4.4 talks about normative server behavior for using this mechanism with INVITE initiated dialogs.
   where is the companion set of normative requirements for using the mechanism to keep alive a REGISTRATION
   flow?

*  In several places, the document refers to an element inspecting "its" Via header. This is imprecise and will
    lead to arguments among implementers. I suggest explicitly calling out "the topmost Via header field value"
   and being very specific about when you are talking about a message being received or a message being sent.

* In section 5's fourth paragraph, it would help avoid confusion  to say "adds a value the a 'keep' parameter to
   indicate willingness" instead of "uses the 'keep' parameter...".

*In the last sentence of Section 5 - what value is "without forcing entities to re-write the value of Flow-Timer
 header field" adding? I suggest deleting the phrase.

* Section 6's first paragraph says "Entities that want to reuse connections MUST use a another mechanism".
   (Note the spurious 'a'). Why is this a 2119 MUST? I suggest saying "would need to" instead.

* The first sentence in 7.4 would be better if it said Figure 3 instead of "The figure". The end of the first
   paragraph has a spurious period.

* All of the examples showing Via header fields use a shorthand, pseudo-code style representation of the
   header field format. It would be good to explicitly note that in the document. It would be better to provide
   one example that was syntactically correct.

* In Section 10's section paragraph. I suggest that you be explicit that you are talking about hop-by-hop
  integrity protection (calling out TLS or DTLS), to avoid confusion with end-to-end integrity protection
  mechanisms (S/MIME) which will not help this case.

* In section 10's third paragraph, you call out "(at high rates)". This is potentially misleading - the rates
  are at the highest somewhere just under once a second. I suggest replacing "(at high rates)" with
  "(up to approximately once a second)".