Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10

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

Hello Ben,
Thanks for your comments and guidance, our responses below.

Regarding " So as written, it seems like protocol/behavior requirements are either spread or repeated between the requirements and solution draft. This seems to make life harder than necessary for the implementer."
Below we have suggested moving some of the requirements draft text to the solutions draft, based on your feedback. With these revisions, the requirements draft covers only the requirements of the log-me mechanism. Specifically, the requirements draft will document "what" are the requirements and "why" is it a requirement. Details about "how" the requirements are implemented in the network element are moved to the solution draft.

Regarding " More to the point: Do you expect an implementor to have to read both this draft and the solutions draft to properly implement the mechanism? If so, then can you clarify the distinction of what would go in this draft vs that one?"
We would expect an implementor to read both. The requirements draft gives a high-level understanding of the motivating scenario, concept definitions (e.g. network boundary), and the requirements themselves. The solution draft then defines the protocol mechanism details. This top down approach of understanding the problem being solved and the concepts around it before implementing a solution seems natural to us.
Also, the working group has been following this top down approach for quite a while as can been seen from the decisions below from 2013 and 2014. We hope that the IESG will understand that the group worked for a long time on acceptable requirements and that it is valuable to freeze them now and publish them as a reference that explains and scopes the problem and defines the target for the solution to fulfil.
During IETF 87, Berlin, 2013 the meeting notes (https://mailarchive.ietf.org/arch/msg/insipid/08l7_9vrzRlmV0qGkgDxDrBi8Ig) say " Log-me requirements: Alternatives to LogMe draft should be submitted in following weeks. Solution draft will come later."
Then at IETF 88, Vancouver, 2013, it is noted (https://www.ietf.org/proceedings/88/minutes/minutes-88-insipid) that "Proposal is to remove the solution text in the current version and adopt the requirements part as WG draft.- Paul K: Had a bunch of comments.  Not sure the subset of requirements is ready to be adopted. There is still a bunch of trust issues with storing the log.- Gonzalo S: Solution discussion has not even begun yet. This is purely the requirements we are talking about"
And the working group milestones have been stable since February 2014 (https://mailarchive.ietf.org/arch/msg/insipid/vxRRrq_OxJyCWZDtHD25U32chCo):
"Changed milestone "Requirements for marking SIP sessions for logging to IESG (Informational)", set due date to September 2014 from June 2014.
Changed milestone "Protocol for marking SIP sessions for logging to IESG (Proposed Standard)", set due date to December 2014 from November 2014."

Regarding REQ1, REQ6, REQ7, REQ8, REQ9, REQ10, REQ11, these have been revised along the lines of your feedback and the new wording is shown below.
REQ6: A "log me" marker is most effective if all networks on the signaling path agree to pass it end-to-end. However, source networks should behave responsibly and not leave it to a downstream network to detect and remove a marker that it is not expecting.

REQ7: The presence of a "log me" marker indicates that a request or response is part of debugging or regression testing.  SIP entities that support "log me" marking SHOULD log SIP requests or responses that contain a "log me" marker."

REQ8: It MUST be possible to insert "log me" marker in SIP responses that correspond to SIP requests with "log me" marker in order to ensure that the complete SIP transaction is logged. This requirement applies to endpoints, SIP/PSTN gateways and B2BUAs.

REQ9: The "log me" marker mechanism SHOULD allow a SIP intermediary to request logging SIP requests and responses on behalf of the originating endpoint. The typical use case for this requirement is for compatibility with UAs that have not implemented "log me" marking, i.e. when a UA has not marked a request or when responses received on a dialog of interest for logging do not contain an echoed "log me" marker. Another use case is when the session origination UA that inserted log me marker is no longer participating in the session (e.g., call transfer scenarios) and the intermediary adds "log me" marker in related sessions to enable end-to-end signaling analysis.

REQ10: The mechanism MUST allow stateless processing of SIP requests that contain a "log me" marker by SIP intermediaries. This requirement enables the SIP intermediaries to base the decision to log a SIP request or response solely on the presence of the "log me" marker.
REQ11: The scope of SIP message logging request includes all requests and responses within a given dialog. The scope can be extended to related dialogs that correspond to an end-to-end session for scenarios discussed in REQ9. The "log me" request MUST be indicated at the beginning of the dialog of interest and SHOULD continue to the dialog end without any stop and restart during the duration of the dialog.

We can revise the paragraph on RFC2119 language as per your feedback.
"2. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], , except that rather than describing interoperability requirements, they are used to describe requirements to be satisfied by the "log-me" marker solution."

Regarding "4.3, third bullet: Is this really limited to a dialog, or do you expect it to apply to the concept of a "session" as described in the session-ID doc?"
In 4.3 "Example Debugging Procedure", the third bullet can be extended in order to not exclude scenarios such as call transfer.
Subsequent responses and requests in the same dialog are also marked with a "log me" marker. For some scenarios, such as call transfer, related dialogs may also be marked with "log me" marker.

Regarding "From your response, I assume the authors consider the "how and when" for log retrieval not to include things like authorization policies, protections against eves droppers, etc. I don't think all readers will make that distinction." We propose the following additional sentence at the end of the paragraph after REQ2 in 5.1 "Message Logs":
When and how signaling logs are retrieved is out of scope of this document.  Logs might be retrieved by logging on to the SIP entity that contains the logs, by sending logs to a central server that is co-ordinating debugging, by storing them on removable media for later manual collection, or by some other method. All log retrieval mechanisms must adhere to authorization and privacy protection policies set forth by the network administrator.

Regarding " On reflection, can you meet the intended use cases without identifying a device or user?"
We believe that we can meet the intended use cases without using the device or user. Neither the session-ID nor the log-me marker contain any user specific or device specific information.

Regarding "On re-reading the paragraph, I see you are correct. But I'm not clear on what that means. Does the "in transit" part and "readable by unauthorized party" part refer to whatever config interface is in use, not something sent in the SIP signaling? Are requirements on the configuration interface in-scope for this document?"
Configuration interface is not in-scope for this draft. "in-transit" was referencing to the data path through which configuration is sent. To keep things simple, we can reword the sentence to use "secure communication channel" as follows:
Section 6.2.1
change third paragraph from:
"Activating a debug mode affects the operation of a terminal, therefore debugging configuration MUST be supplied by an authorized party to an authorized terminal, debugging configuration MUST NOT be altered in transit, and MUST NOT be readable by an unauthorized third party."
to:
"Activating a debug mode affects the operation of a terminal, therefore debugging configuration MUST be supplied by an authorized party to an authorized terminal through a secure communication channel."

Regarding " The requirement that logs not be readable by an unauthorized party seems to contradict the earlier statement that how and when logs are read is out of scope."
This should be covered in our previous e-mail response by moving the last paragraph of 6.2.1 " "Log Me" Marking" to replace the paragraph in 6.2.2 "Logged Information". In this way, the text applies only to the logged information itself, not its retrieval (in response to our last e-mail, you indicated that you are OK with removing the redundancy in 6.2.1 in this way). Section 6.2.2 then becomes:
"6.2.2.  Logged Information
Logged signaling is privacy-sensitive data, therefore signaling logs MUST NOT be readable by an unauthorized third party."


We plan to post a new revision of the logme-reqs draft when all of your comments are resolved.

Thanks again,
Arun and Peter (co-authors)

From: DOLLY, MARTIN C [mailto:[e-mail]]
Sent: 24 November 2016 02:20
To: Ben Campbell
Cc: Dawes, Peter, Vodafone Group; Arun Arunachalam; [e-mail]; Gonzalo Salgueiro; [e-mail]
Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10

Longer than most of my short answers
Initially meant in controlled deployments

Maybe SIP or now the world version of SiP being done in 3GPP.

Not IETF. In would have been interoperable

Sorry
Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:[phone]>
Email: [e-mail]<mailto:[e-mail]>


On Nov 23, 2016, at 9:02 PM, Ben Campbell <[e-mail]<mailto:[e-mail]>> wrote:
I'm not sure I follow you, but I assume you either mean either that you like version 10 the way it is, or you like some component of it better than my suggestion.

Please note that my proposals on requirements language, which I think are the most material suggestions, are contingent on the answers to some of my earlier questions about how the behavior definition is divided between this and the solution draft.

Ben.

On 23 Nov 2016, at 19:08, DOLLY, MARTIN C wrote:


Ben

The initial proposal was easier

UGH

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:[phone]>
Email: [e-mail]<mailto:[e-mail]><mailto:[e-mail]>


On Nov 23, 2016, at 7:34 PM, Ben Campbell <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>> wrote:

Hi, thanks for the response. Comments inline.

Ben.

On 23 Nov 2016, at 8:59, Dawes, Peter, Vodafone Group wrote:

Hello Ben,
Thanks very much for your initial AD evaluation of draft-ietf-insipid-logme-reqs-10, below is our response. The review was long so we used some XML-style tags to structure the response according to your major and minor concerns.

Regards,
Peter and Arun (co-authors)

<major-issue-1>
- What is the archival value for this draft after the mechanism is complete? Is there really a reason to publish it as an RFC? Could the info here be stored in the working group wiki, included in the solution draft, or even allowed to expire once the mechanism is complete? I contrast this to the session-id requirements document, since that explored the details of some tricky concepts (such as "session".) It's not clear to me that this draft does the same. I also note that logme-marking already seems to replicate a good deal of this draft, and seems to dive even deeper into use cases, and in some areas seems to have moved beyond the requirements in this draft.
I ask because the question is likely to come up in IESG review, and also because the publication process creates a lot of effort for the working group, RFC editor, reviewers, etc.
</major-issue-1>

<reply-1>
The primary objective of a requirements draft is to provide clarity on the complete list of requirements that a proposed solution needs to satisfy for a given problem. In our logging and troubleshooting scenarios, the requirements list has been identified through discussions and consensus among INSIPID working group members.

That's my understanding of what a requirements draft typically does. But this draft seems to also put requirements on behavior, which seem like protocol requirements to me. So as written, it seems like protocol/behavior requirements are either spread or repeated between the requirements and solution draft. This seems to make life harder than necessary for the implementer.

There are other reasonable work divisions, for example you might have an requirements + architecture draft and a separate solution draft, or you might have a SIP element behavior draft and a data format draft, etc.



In this draft, we have clearly documented the requirements from the perspective of:
-    When the logging is started and stopped
-    Passing the log-me marker across SIP entities
-    Privacy considerations

These are all reasonable categories. My concern is how things are divided between this and the solution draft within those categories. For example, a requirement of the form of "The logging indication must be able to be sent across B2BUAs" vs "A B2BUA must copy the <foo> parameter".



The solution document will provide insights into the "how" details. These two documents help a network developer, administrator and support engineer to understand the guiding requirements upon which the solution will be built