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

From: Mary Barnes <[email-masked]>
Date: Wed, 5 Sep 2012 18:03:45 -0500

Robert and WG,

We have submitted an updated version that we believe addresses the concerns
raised, per the responses below.  Here's the diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-09
*
*
Please let us know if you are okay with these changes.

Regards,
Mary et al

On Fri, Aug 24, 2012 at 1:45 PM, Robert Sparks <[email-masked]> wrote:

> 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?
>
[MB] No.  We have removed the call flows from this document and have added
a reference to the call flows document. [/MB]

>
> 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?
>
[MB]  We have updated the text to reflect that only mp and rc are relevant
in this scenario.  [/MB]

>
> 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).
>
[MB] We have added text to indicate that it is simply that the URI in the
hi-entry doesn't match the request URI.  Hopefully, the text around the .0
is more clear. [/MB]

>
> 4) The Changes from RFC4244 section doesn't call out the new .0. gap
> detection/representation mechanic.
>
[MB] That's been added. [/MB}

>
> 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?
>
[MB] We added text indicating that this needs to be considered per the
application considerations section (i.e., applications need default
behavior in the case of missing information in per 4244 and now this
document).  [/MB]

>
>
> 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?
>
[MB] We just clarified that this reflects the retargeting.  The "nesting"
concept is leftover from 4244 - it was referring to the number of dots.
 [/MB]

>
> 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.
>
[MB] It really makes the text much less clear when we lose the concept of a
cache.  That was John Elwell's suggestion and it really describes how the
information in the incoming request needs to be somehow maintained to build
the outgoing requests.  We have added text noting that the cache is just a
copy. This is actually quite consistent (including use of normative
language) with RFC 3261 when it describes the copying of information for
the process of forwarding a request.  [/MB]

>
> First paragraph of 10.4 still says "two header field parameters" and
> "Both", but talks about three.
>
[MB] Fixed. [/MB]

>
> "As for the behavior of the entity followings have changed" does not parse.
>
[MB] Fixed. [/MB]

>
> 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.
>
[MB] No longer there since we removed the call flows. [/MB]

>
> ______________________________**_________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 06 Sep 2012 13:18:30 -0500

Thanks Mary -

I agree these address my points. I'm requesting IETF LC on this version.

SIPCORE - please review these changes carefully.

RjS

On 9/5/12 6:03 PM, Mary Barnes wrote:
> Robert and WG,
>
> We have submitted an updated version that we believe addresses the 
> concerns raised, per the responses below.  Here's the diff:
> /
> /
> On Fri, Aug 24, 2012 at 1:45 PM, Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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?
>
> [MB] No.  We have removed the call flows from this document and have 
> added a reference to the call flows document. [/MB]
>
>
>     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?
>
> [MB]  We have updated the text to reflect that only mp and rc are 
> relevant in this scenario.  [/MB]
>
>
>     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).
>
> [MB] We have added text to indicate that it is simply that the URI in 
> the hi-entry doesn't match the request URI.  Hopefully, the text 
> around the .0 is more clear. [/MB]
>
>
>     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?
>
>     requests". It's the only place the word nesting occurs in the
>     document. Could you provide a description/definition or a pointer
>     to one?
>
> [MB] We just clarified that this reflects the retargeting.  The 
> "nesting" concept is leftover from 4244 - it was referring to the 
> number of dots.  [/MB]
>
>
>     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.
>
> [MB] It really makes the text much less clear when we lose the concept 
> of a cache.  That was John Elwell's suggestion and it really describes 
> how the information in the incoming request needs to be somehow 
> maintained to build the outgoing requests.  We have added text noting 
> that the cache is just a copy. This is actually quite consistent 
> (including use of normative language) with RFC 3261 when it describes 
> the copying of information for the process of forwarding a request.  [/MB]
>
>
>     First paragraph of 10.4 still says "two header field parameters"
>     and "Both", but talks about three.
>
> [MB] Fixed. [/MB]
>
>
>     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.
>
>     _______________________________________________
>     sipcore mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/sipcore
>
>