Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis

["Elwell, John" <[e-mail]>]

Mary,

I have responded below, stripping out the stuff where I have nothing further to add. 

> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]] 
> Sent: 01 November 2010 19:25
> To: Elwell, John
> Cc: [e-mail]
> Subject: Re: [sipcore] REMINDER: Re: WGLC: 
> draft-ietf-sipcore-rfc4244bis
> 
> John,
> 
> I apologize for missing these in the round of -02 changes. Per the
> other email thread, some of these are no longer relevant due to the
> extent of changes and some were redundant with issues raised
> (individually) in the tracker.   So, I'll just responsd to  those that
> are still relevant [MB].  I will note that one thing that would help
> me  to avoid losing document reviews in my mailbox is that if folks
> could change the "Reminder" to (or prepend) the term "Review" (or
> "Comments") so that the email is a bit easier to find when one's
> mailbox is overflowing with issues from the issue tracker.
[JRE] Yes, good idea.

> 
> Thanks,
> Mary.
> 
> On Tue, Aug 31, 2010 at 11:32 AM, Elwell, John
> <[e-mail]> wrote:
> > I have reviewed the document as far as section 8, before 
> running out of time. Although the technical content of the 
> document is reasonably stable, there are far too many minor 
> problems that need fixing before it is ready to go. Specific comments:
> >
> > 1. In general, there are too many normative statements 
> (MUST/SHOULD) written in the passive voice, or in the active 
> voice with an inappropriate subject. I have pointed out a few 
> of these in later comments, but all should be checked.
> >
> > 2. It nearly always uses the term "header" rather than 
> "header field", although never, as far as I know, meaning the 
> entire SIP header.
> [MB] I'm not sure that I fully understand the concern. Can you point
> out a specific sentence or section of concern?  The term "header" is
> used when it is referring to the History-Info header field, but that
> is done in other documents as well.  In general, I think it's
> understood that it's referring to the header field when it's
> qualified. Perhaps you're referring to places where it is not
> qualified?   The term hi-entry is used, as well.
> [/MB]
[JRE] I have explained in more detail in my comments on -02.

<snip/>

> >
> > 7. Section 4.1:
> > "and if the Request-URI was modified by a previous hop"
> > What is a hop? I tend to think of a hop as being the "wire" 
> between two SIP entities, but here it seems to be used to 
> mean a SIP entity such as a proxy. If we really want to use 
> this term, we should define it. Check for other instances too.
> [MB] I will change this to "previous SIP hop". Note that the term
> "hop" is used throught RFC 3263. If you would like, I could add a note
> in the terminology that the term is consistent with that. [/MB]
[JRE] I am not even sure it is consistent in RFC 3263. Anyway, given existing mixed usage of the term, I withdraw the comment.

<snip/>

> >
> > 15. Section 4.2.1:
> > "the
> >   UAS MUST insert an hi-entry ."
> > How is this testable, other than by the fact that H-I will 
> get reflected in the response? But that should be covered in 
> 4.2.2, shouldn't it?
> [MB] It's not testable on the wire. However, to applications at the
> UAS expecting that entry to be in a request that they might receive,
> it would seem appropriate that the field be added to the Request that
> is presented to any application. Doing that also ensures it will be in
> the response which is what the text currently states. I do not think
> that applications should be screening the information it receives to
> look for this situation. [/MB]
[JRE] OK, I can live with it as it is.

<snip/>

> >
> > 17. Section 4.2.2:
> > "The information can also be useful for
> >   implementations with B2BUAs that include the 
> History-Info, received
> >   in the incoming request, in the subsequent outgoing request."
> > The words "implementations with B2BUAs" seem strange - why 
> not just "B2BUAs"?
> [MB] I don't see this text in section 4.2.2. of -01 nor 5.2.2 of -02.
>  I think you are referring to section 4.2.1.  I'll change that it was
> trying to qualify a B2BUA as something that was very implementation
> specific and not standard SIP per se. [/MB]
[JRE] Yes, sorry, it was 4.2.1.

> >
> > 18. Section 4.2.2:
> > "the UAS MUST
> >   include any History-Info received in the request  in the 
> subsequent
> >   response"
> > Does this include 100 responses?
> [MB] I would think so. Can you think of a reason why it shouldn't?  I
> would think it could be useful for debug. [/MB]
[JRE] The 100 response typically only travels back a single hop, so the benefit of H-I in a 100 is marginal. Also some implementations might send back a 100 response quite early during processing, perhaps even before they decide whether to act as a proxy, a UAS or a redirect, so knowing how to populate H-I in a 100 might be difficult.

<snip/>
> >
> > 25. Sections 5.1.2 and 5.1.3. These are different, in that 
> 5.1.2 allows for multiple branches failing, but 5.1.3 allows 
> for only a single request encountering 3xx. Firstly, it is 
> possible >1 request can return 3xx (the proxy is not forced 
> to recurse immediately the first 3xx arrives). Secondly it is 
> possible that some failure responses might arrive before the 
> 3xx on which the proxy recurses. I think the new request 
> should reflect H-I from all previous branches, not just the 
> one leading to recursion. Also the tagging of the recursed 
> request should take account of all previous branches.
> [MB] Yes - the redirection case should be consistent.  And, really I
> don't know that we need a separate case for redirection as I agree it
> should send the aggregate information, as well.  [/MB]
[JRE] I think I made a similar comment on -02 already. Anyway, we seem to be in agreement.

> >
> > 26. Section 5.2:
> > "A proxy that receives a request with the "histinfo" option 
> tag in the
> >   Supported header, SHOULD forward captured History-Info in 
> subsequent,
> >   provisional , and final responses "
> > Does this include 100 responses?
> [MB] That's the implication of "provisional" per RFC 3261. [/MB]
[JRE] I am doubtful about the usefulness of 100. However, it is probably fairly academic, since 100 will probably have been sent earlier. A proxy is unlikely to send a 100 after receiving a provisional response from a downstream entity.

> >
> > 27. Section 5.2:
> > "A proxy MAY anonymize any hi-entry whose domain corresponds to a
> >   domain for which it is responsible (as per [RFC3323 ])."
> > I don't think RFC 3323 tells me how to anonymize an hi-entry.
> [MB]  RFC 3323 discusses anonymization and the role of an anonymizer,
> etc. So, I'm not clear on your concern. [/MB]
[JRE] I guess if we talked about anonymizing the URI in the hi-target-to-uri it would be clearer.

<snip/>


John