Subject: [sipcore] AD review: draft-ietf-sipcore-rfc4244bis-08

From: Robert Sparks <[email-masked]>
Date: Fri, 24 Aug 2012 13:45:59 -0500

Summary: There are a couple of questions to discuss before progressing 
to IETF LC.

This document is much easier to follow than RFC4244. It is still 
complex, but the rewrite effort improved its readability significantly.

There are a couple of things I would like the WG to consider before 
moving into IETF LC.

1) Since the WG adopted the call-flows document, does this document 
still need Appendix A, or should any of the examples there that are not 
already in the call-flows document be moved to that document?

2) The document requires that redirect servers include an 
hi-target-param in the Contact header fields it provides, and requires 
elements recursing on redirect responses to only include 
hi-target-params that it finds in those Contacts. They are specifically 
forbidden from providing the param if there are no params in the 
Contact. Please consider saying why this is required. If I recall the 
conversation correctly, it's because the redirect server is the only 
element that can tell whether mp or rc would be appropriate. For np, 
however, it's not clear why this requirement exists.  Is it just to keep 
things simple?

3) Section 103 step 6 says "If the request clearly has a gap", but I 
don't see any description of what an element is supposed to look for to 
determine there is a gap. From a discussion with Mary, it should be as 
simple as comparing the last HI entry to the Request-URI. If that's 
right, please add that to this description, and make it clear that you 
would only add one .0. when identifying a gap, not try to figure out how 
many elements may have not added history (that is, you would never 
produce something that looked like 1.0.0.1).

4) The Changes from RFC4244 section doesn't call out the new .0. gap 
detection/representation mechanic.

5) The backwards compatibility consideration focuses on exploring how 
RFC4244 elements will deal with messages created following this 
specification. There should be some additional exploration of how 
elements implementing this specification will deal with messages created 
by RFC4244 elements. Those messages could be missing things this 
specification says MUST be there. Can we make it more likely that an 
implementer won't create code that rejects such messages as malformed?

Nits:

At the definition of hi-index, the document talks of "nesting of 
requests". It's the only place the word nesting occurs in the document. 
Could you provide a description/definition or a pointer to one?

The description of using an internal cache to describe how an element 
will construct the history-info values it emits is likely to draw 
discussion during IETF/IESG review. It uses 2119 language to describe a 
possible implementation. Please consider changing the phrasing to make 
it clear that the normative constraints are on what's emitted, not on 
they way you store the information internally.

First paragraph of 10.4 still says "two header field parameters" and 
"Both", but talks about three.

"As for the behavior of the entity followings have changed" does not parse.

In the first example in appendix A, the Contact in F3 has no parameters, 
but the corresponding H-I value in F4 has an mp=1. The version of this 
example in the callflow doc has the mp=1 in the Contact in the 302.