An Extension to the Session Initiation Protocol (SIP) for Request History Information
draft-ietf-sip-history-info-06

(from review by Michael Patton)

I had two concerns, neither of which is strong enough to warrant
delaying the document, although if they are easy to fix that would be
worth it.

I'm not sure I believe the "stronger security" claim at the end of
Section 1.  I see this as analogous to the BGP problem.  Even though
each link was secured, in the end you can't be sure of anything except
the link closest to you.  Now, this _may_ be stronger than basic SIP
in some sense, but it's not really compelling to me.  Possibly because
I iniitally thought the per-hop securing of BGP was good enough until
in an hour-long discussion with a security person, I was finally
convinced that it only helped very marginally, if at all, and
contributed mostly to a false sense of security.

When I first started reading Section 2 I saw the "-req" notation as
short for request but later realized it was probably intended to be
short for requirement.  Is that correct?  I suggest that this
potential confusion could lead to readers making errors and, unless
it's following some established precedent, I'd recommend using
something like "-rqmt" which is less likely to be confused.


There were also a few typos I saw, which can just be fixed by RFC-Ed:
---------------------------------------------------------------------

At the very end of 4.1 one of the entries in the BNF is indented an
	extra space.

Section 4.5: "would try several some of the same places" either
	"several" or "some" should be removed,

Appendix A: "UA 1sends" => "UA1 sends"

It would be helpful to have the ballot write-up included when the ballot is issued.

Suggested text for 4.3.1

OLD:
    
  The UAC SHOULD include the "histinfo" option tag in the Supported 
  header in any request not associated with an established dialog for 
  which the UAC would like the History-Info header in the Response.  In 
  addition, the UAC SHOULD initiate the capturing of the History 
  Information by adding a History-Info header, using the Request-URI of 
  the request as the hi-targeted-to-uri and initializing the index to 
  the RECOMMENDED value of 1 in the hi-entry.  

NEW:

In 4.3.1, the draft says:

    
  The UAC SHOULD include the "histinfo" option tag in the Supported 
  header in any request not associated with an established dialog for 
  which the UAC would like the History-Info header in the Response.  In 
  addition, the UAC MAY initiate the capturing of the History 
  Information by adding a History-Info header, using the Request-URI of 
  the request as the hi-targeted-to-uri and initializing the index to 
  the RECOMMENDED value of 1 in the hi-entry.  By initiating the capturing
  of the History Information, the UAC ensures that in cases of retargeting
  without further population of the header, the end consumer can at 
  minimum detect that its was not the original target URI.