80 likes | 161 Views
SIP WG Meeting IETF-59. Request History Information. draft-ietf-sip-history-info-02.txt. Mary Barnes (mary.barnes@nortelnetworks.com). Changes from -01. Miscellaneous editorial nits. Merged the SIPPING WG requirements draft into this document.
E N D
SIP WG Meeting IETF-59 Request History Information draft-ietf-sip-history-info-02.txt Mary Barnes (mary.barnes@nortelnetworks.com)
Changes from -01 • Miscellaneous editorial nits. • Merged the SIPPING WG requirements draft into this document. • Removed redirect server from ISSUER-req since the solution identified this as not being required (or desirable). • Added an explicit privacy requirement (PRIV-req-3) for the proxy's role in recognizing and maintaining privacy associated with a Request-URI being captured in History-Info due to local policy. (Note, that the text was already there, it just wasn’t highlighted as an explicit requirement). draft-ietf-sip-history-info-02
Changes from -01 • Clarified the use of CRLF and spacing in the example in section 4.2. • Removed the compact form for the header since unknown headers with multiple entries would not be recognized (i.e. this may cause parsing problems). • Added a summary of Application Considerations to address concerns about the optional usage of History-Info. draft-ietf-sip-history-info-02
Issue 1 – Privacy – addt’l tags • Proposal • Add an additional field to tag HI entries that are added when privacy restrictions are involved. • Indicates whether the entry is to be removed when it’s being forwarded outside that domain (per local policy). • Allows network services to make use of the information within the domain. • Need more list discussion as to whether this is a good idea. • Privacy • Previous discussion on this point resulted in keeping things simple and if there are privacy considerations indicated by the Privacy header or local policy, then History-Info is not included. • This didn’t preclude local policies that might allow the information to be added, but required it be removed when leaving that domain. • Issue: • Folks wanting to make use of History-Info indicate this isn’t sufficient. draft-ietf-sip-history-info-02
A. Options for a mechanism: • Keep only the 1st and last index in a branch. • Keep only x. • Keep only to a certain depth or breadth. Issues with option A: • How is this option indicated? • When would the option be applied? • Only when you hit a certain limit or always? • Local policy? • Need more list discussion as to whether this is a good idea. Issue 2 – Limit the number of entries? • Should or can there be a limit on the number of History-info entries captured? • Issue: implementors have indicated that messages get quite large with lots of retargets. • Options: A. Define a mechanism that allows “pruning” of the entries. B. Leave it to the end applications (i.e. protocol shouldn’t define this). draft-ietf-sip-history-info-02
Next Steps • Request additional feedback on the mailing list on open issues. • Feedback in the form of alternative text on any other issues identified is most constructive. • Update the flows in the appendix including additional details & annotations. • Dependency on the security solution as identified by the requirements draft: draft-barnes-sipping-sec-inserted-info-01.txt draft-ietf-sip-history-info-02
Backup draft-ietf-sip-history-info-02
B is serial forking first to C then to D. C is parallel forking. Solution draft – History-Info – Index Example A B C E | \ F | \ D G • A sends INVITE targeted to B. HI: B, n=1. • B retargets to C. HI: B, n=1; C, n=1.1 is sent in INVITE and response to A. • 3) C parallel forks to E and F. • HI: B, n=1; C, n=1.1; E, n=1.1.1 sent in INVITE to E and response to B,A • HI: B, n=1; C, n=1.1; F, n=1.1.2 sent in INVITE to F and response to B,A • 4) both branches of fork to C fail. B retargets to D with the following History Info entries: • HI: B, n=1; C, n=1.1; E, n=1.1.1; F, n=1.1.2; D, n=1.2 draft-ietf-sip-history-info-02