[Insipid] draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged"

["Dawes, Peter, Vodafone Group" <[e-mail]>]

Hello All,
To follow up on the logme requirements being published as RFC 8123, the corresponding solution draft https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ has been revised and uploaded as -07.

Changes in this version are from a few sources. The requirements draft contained some detailed solution-related text that has been moved to the solution draft. The IESG review of the requirements draft highlighted a number of corrections and concerns including privacy. A review that Paul Giralt sent to this list a while back identified some changes. Also, the authors restructured and clarified the descriptions throughout.  The changes are all summarized below.

We have tried to be comprehensive in describing procedures and answering review concerns in this version and it would be good to hear if issues remain.

Thanks!
Peter and Arun (co-authors)

**Changes as a result of review of requirements draft by Dan Romascanu and moving text from the requirements to the solution draft**
In "2.  Conventions Used in this Document added text to expand the applicability of requirements language.
Added a new high-level clause "Marking Related Dialogs" to describe "log me" marking related dialogs.
Defined the SIP CLF format for logs in "Format of Logged Signaling".
Restructured "Security Considerations".
Trust domain behavior described in end-to-end marking clause.
Restructured with high-level "Stateful and Stateless SIP Entities" clause.
End-to-end marking section clarifies that "log me" marking does not contain any user or device specific information.
"Authorizing logme Marking" section added to Security Considerations



**Changes resulting from review of requirements draft by Stephen Farrell, Kathleen Moriarty
Moved "Trust Domain" sub-clause from "Security Considerations" to the body of the draft and re-named it "End-to-End Marking"
Added a "Privacy" sub-clause in "Security Considerations".
Did a privacy analysis as described in RFC 6973 and as a result completely restructured and revised the Privacy section.



**Changes as a result of review by Paul Giralt
Section 5.1 on configuration removed. Configuration does not need to be described in any detail as it is out of scope of the document.
Example of calling/called party number added to section "Starting and Stopping logme Marking".
Text revised to "log me" marking MUST be copied into forked requests.
Section 4.2.1.2.1 describes B2BUA terminating behaviour (since according to RFC 7092, a signaling only B2BUA can manipulate SIP in any way it likes.)
References to RFC 7206 changed to references to RFC 7989.
In section 6.5, text revised to "A SIP entity that has logged information MUST protect the logs, such that the logs can only be read by a person authorized to do so."
Text added to introduction stating that session identity must be implemented for this document. RFC7989 added to normative references.
logme-reqs moved to informative references.
Syntax of all references revised.
Revised section "Identifying Test Cases" to align with description in the requirements draft.


**Authors updates
Text in 5.1 moved to clause 4 and revised to clarify that the example of using XML to show configuration is only an example. The draft does not formalize how configuration is done.
Text revised to say that it is operator knowledge that some user agents do not support "log me" and that a SIP entity must act on behalf of the user agent
Revised text for both originating and terminating proxies to say that they MUST log signaling.
Replaced text and figure in 5.4 with a list of 4 cases for maintaining state and 4 figures that illustrate each one.
Replaced figure with four figures based on a call flow example from RFC 3665. The new figures are simpler and have a single proxy in originating and terminating networks.
Currently the signaling B2BUA is subject to the same rules as a user's UA, i.e. it cannot invoke "log me" marking on dialogs that it creates without configuration to do so. Text is revised to clarify why this restriction exists, and perhaps this rule can be re-visited if cases for breaking the rule emerge.
debug parameter renamed logme.
Split the "Maintaining State" clause into sub-clauses that describe stateless and stateful behavior.

Restructured the entire draft into a more natural order of describing the "log me" marker, SIP entity behavior, error cases, and security.

Consistent use of "log me" term.

Referenced RFC8123 instead of I-D.ietf-insipid-logme-reqs

Updated ABNF definition (Figure 7) to define header field parameter as "logme"