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

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Fri, 9 Dec 2016 16:58:22 +0000

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:[email-masked]]
Sent: 24 November 2016 02:20
To: Ben Campbell
Cc: Dawes, Peter, Vodafone Group; Arun Arunachalam; [email-masked]; Gonzalo Salgueiro; [email-masked]
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:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Nov 23, 2016, at 9:02 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> 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:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>

On Nov 23, 2016, at 7:34 PM, Ben Campbell <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> 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

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 12 Dec 2016 16:34:06 -0600

Hi,

All of your responses look reasonable, pending seeing them in the 
context of the document. Please submit the new version when you are 
ready.

Thanks!

Ben.

On 9 Dec 2016, at 10:58, Dawes, Peter, Vodafone Group wrote:

> 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.
>
> 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.
>
> 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
> "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:
> Logged signaling is privacy-sensitive data, therefore signaling logs 
> MUST NOT be readable by an unauthorized third party."
>
>
> Cc: Dawes, Peter, Vodafone Group; Arun Arunachalam; [email-masked]; 
> Gonzalo Salgueiro; [email-masked]
> On Nov 23, 2016, at 9:02 PM, Ben Campbell 
> <[email-masked]<mailto:[email-masked]>> 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 Nov 23, 2016, at 7:34 PM, Ben Campbell 
> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> 
> wrote:
>
> 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,
> - 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.
>
>
>
> 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

---

From: "Arun Arunachalam (carunach)" <[email-masked]>
Date: Tue, 13 Dec 2016 12:15:22 +0000

Thanks Ben !

We will submit the new version soon.

Thanks!
Arun

On Dec 12, 2016, at 5:34 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

All of your responses look reasonable, pending seeing them in the context of the document. Please submit the new version when you are ready.

Thanks!

Ben.

Hello Ben,

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.

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.

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:

Thanks again,

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

Sorry
Martin C. Dolly

Ben.

Ben

UGH

Martin C. Dolly

Ben.

Hello Ben,

Regards,

<major-issue-1>

<reply-1>

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 15 Dec 2016 13:54:04 +0000

Hi Ben,
The new version of logme-reqs is uploaded as https://www.ietf.org/id/draft-ietf-insipid-logme-reqs-11.txt. The complete list of revisions resulting from your review and the subsequent discussion is below. Most of the changes to requirements text have been made in order to remove SIP entity behaviour descriptions from the requirements draft so that they can be moved to the solutions draft.

Thanks,

-11: December 2016
   In "2.  Conventions Used in this Document" added the following clarification: ", except that rather than describing interoperability requirements, they are used to describe requirements to be satisfied by the "log-me" marker solution."
   In "4.3.  Example Debugging Procedure" added the following text to the third bullet: ".  For some scenarios, such as call transfer, related dialogs may also be marked with "log me" marker."
   Revised REQ1 from
      "REQ1: The entire SIP message (SIP headers and message body) MUST
      be logged using the SIP CLF format defined in [RFC6873], with
      Vendor-ID = 00000000 and Tag = 02 in the <OptionalFields> portion
      of the SIP CLF record (see [RFC6873] clause 4.4)."
      to
      "REQ1: If a SIP message is logged then the entire SIP message (SIP
      headers and message body) MUST be logged using standard logging
      format such as SIP CLF defined in [RFC6873]."
   Added the following text to the end of the paragraph below REQ2: "All log retrieval mechanisms must adhere to authorization and privacy protection policies set forth by the network administrator."
   In REQ5, deleted the words "by the debugging server to " from "The test case identifier does not have any impact on
      session setup, it is used by the debugging server to collate all logged SIP requests and responses to the initial SIP request in a dialog or standalone transaction." because log retrieval is out of scope.
   Revised REQ6 from
      "REQ6: A "log me" marker is most effective if it passes 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
      will not use.  A "log me" marker SHOULD be removed at trust domain
      boundaries."
   to
      "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."
   Revised REQ7 from
      "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."  The SIP entity checks
      for the presence of a "log me" marker and writes any request or
      response that contains a "log me" marker to a log file."
   to
      "REQ7: The presence of a "log me" marker indicates that a request
      or response is part of debugging or regression testing."
   Revised REQ8 from
      "REQ8: If a UA that supports "log me" marking receives a request
      with a "log me" marker, it MUST echo that "log me" marker in
      responses to that request.  This requirement applies to cases
      where the UA is the endpoint of communication, where the UA is one
      side of a gateway such as a SIP/PSTN gateway, and where the UA is
      one side of a B2BUA."
   to
      "REQ8: It MUST be possible to insert a "log me" marker in SIP
      responses that correspond to SIP requests with a "log me" marker
      in order to ensure that the complete SIP transaction is logged.
      This requirement applies to endpoints, SIP/PSTN gateways and
      B2BUAs."
   Revised REQ9 from
      "REQ9: A SIP intermediary MAY insert a "log me" marker into
      requests and responses.  The typical case for which a intermediary
      needs to insert a "log me" marker 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.  In
      these cases, the entity that inserts a "log me" marker is stateful
      inasmuch as it must remember when a dialog is of interest for
      logging.  An entity that inserts a "log me" marker SHOULD also log
      the SIP request or response as per REQ4."
   to
      "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."
   Revised REQ10 from
      "REQ10: SIP intermediaries MAY be stateless in terms of logging of
      SIP requests that contain a "log me" marker, i.e. they MAY base
      the decision to log a SIP request or response solely on the
      presence of the "log me" marker.  For example, it is OPTIONAL for
      a SIP entity to maintain state of which SIP requests contained a
      "log me" marker in order to log responses to those requests.
      Echoing a "log me" marker in responses is the responsibility of
      the UA that receives a request."
   to
      "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."
   Revised REQ11 from
      "REQ11: "log me" marking of requests and responses MUST be applied
      on a per-dialog granularity.  If applied, "log me" marking MUST
      begin with the dialog-creating request and SHOULD continue to the
      dialog end. "log me" marking SHOULD be applied to in-dialog
      requests and responses in either direction. "log me" marking MUST
      NOT be stopped and re-started on a given dialog."
   to
      "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."
   In section 6.2.1 "Log Me" Marking, added the following text to the end of the first paragraph: "The "log me" marker MUST
   NOT reveal any information related to any SIP user or device."
   In section 6.2.1 "Log Me" Marking, added a new second paragraph as follows:
      "The insertion of "log me" marker at the endpoint MUST be approved by
      the end user or by the network administrator.  Similarly, network
      administrator authorization is required for a SIP intermediary to
      insert a "log me" marker on behalf of an UA that does not support
      "log me" marking."
   In section 6.2.1 "Log Me" Marking, revised the final 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."
   In section 6.2.1 "Log Me" Marking, moved the final paragraph "Logged signaling is privacy-sensitive data, therefore signaling logs MUST NOT be readable by an unauthorized third party." to replace the text in section 6.2.2 "Logged Information"

From: Arun Arunachalam (carunach) [mailto:[email-masked]]
Sent: 13 December 2016 12:15
To: Ben Campbell
Cc: Dawes, Peter, Vodafone Group; [email-masked]; Gonzalo Salgueiro (gsalguei); [email-masked]; DOLLY, MARTIN C; Arun Arunachalam (carunach)
Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10

Thanks Ben !

Thanks!
Arun

Hi,

Thanks again,

Sorry
Martin C. Dolly

Ben.

Ben

UGH

Martin C. Dolly

Ben.

Hello Ben,

Regards,

<major-issue-1>

<reply-1>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 21 Dec 2016 15:27:28 -0600

Thanks! I think this version is ready for IETF Last Call.

One thing to consider (in parallel to the last call) is if you want to 
say anything about log minimization for privacy purposes. For example, 
is it always necessary to log the entire SIP message?  are there use 
cases where one might log a subset, to avoid logging of information not 
necessary for the purpose? As written, the requirements don't seem to 
allow that--should they?

I mention this because I expect it to come up either during the LC or 
IESG evaluation. It might help to have already thought about that if it 
does. (Again, I don't think this need block the last call.)

Thanks!

Ben.

On 15 Dec 2016, at 7:54, Dawes, Peter, Vodafone Group wrote:

> Hi Ben,
> The new version of logme-reqs is uploaded as 
> https://www.ietf.org/id/draft-ietf-insipid-logme-reqs-11.txt. The 
> complete list of revisions resulting from your review and the 
> subsequent discussion is below. Most of the changes to requirements 
> text have been made in order to remove SIP entity behaviour 
> descriptions from the requirements draft so that they can be moved to 
> the solutions draft.
>
> Thanks,
>    In "2.  Conventions Used in this Document" added the following 
> clarification: ", except that rather than describing interoperability 
> requirements, they are used to describe requirements to be satisfied 
> by the "log-me" marker solution."
>    In "4.3.  Example Debugging Procedure" added the following text to 
> the third bullet: ".  For some scenarios, such as call transfer, 
> related dialogs may also be marked with "log me" marker."
>    Revised REQ1 from
>    Added the following text to the end of the paragraph below REQ2: 
> "All log retrieval mechanisms must adhere to authorization and privacy 
> protection policies set forth by the network administrator."
>    In REQ5, deleted the words "by the debugging server to " from "The 
> test case identifier does not have any impact on
>       session setup, it is used by the debugging server to collate all 
> logged SIP requests and responses to the initial SIP request in a 
> dialog or standalone transaction." because log retrieval is out of 
> scope.
>    Revised REQ6 from
>    In section 6.2.1 "Log Me" Marking, added the following text to the 
> end of the first paragraph: "The "log me" marker MUST
>    In section 6.2.1 "Log Me" Marking, moved the final paragraph 
> "Logged signaling is privacy-sensitive data, therefore signaling logs 
> MUST NOT be readable by an unauthorized third party." to replace the 
> text in section 6.2.2 "Logged Information"
>
>
> Cc: Dawes, Peter, Vodafone Group; [email-masked]; Gonzalo Salgueiro 
> (gsalguei); [email-masked]; DOLLY, MARTIN 
> C; Arun Arunachalam (carunach)
> On Dec 12, 2016, at 5:34 PM, Ben Campbell 
> 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.
>
> 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 
> 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.
> discussed in REQ9. The “log me” request MUST be indicated at the 
> Regarding “4.3, third bullet: Is this really limited to a dialog, or 
> in the session-ID doc?”
> 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
> Cc: Dawes, Peter, Vodafone Group; Arun Arunachalam; 
> [email-masked]<mailto:[email-masked]>; Gonzalo Salgueiro; 
> [email-masked]<mailto:[email-masked]>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 21 Dec 2016 21:31:19 +0000

Authors: Perhaps have a look at the Security Considerations section of RFC 6872 and 6873 as preparation for questions that may arise regarding storage, transport, privacy, securing, etc of logged material.

-G

> On Dec 21, 2016, at 4:27 PM, Ben Campbell <[email-masked]> wrote:
> 
> One thing to consider (in parallel to the last call) is if you want to say anything about log minimization for privacy purposes. For example, is it always necessary to log the entire SIP message? are there use cases where one might log a subset, to avoid logging of information not necessary for the purpose? As written, the requirements don't seem to allow that--should they?
> 
> I mention this because I expect it to come up either during the LC or IESG evaluation. It might help to have already thought about that if it does. (Again, I don't think this need block the last call.)
> 
> Thanks!
> 
> Ben.
> 
> On Dec 12, 2016, at 5:34 PM, Ben Campbell <[email-masked]> wrote:
>  
> Hi,
> Cell: +1.609.903.3360
> Email: [email-masked]
> On Nov 23, 2016, at 9:02 PM, Ben Campbell <[email-masked]> wrote:
> 
> On Nov 23, 2016, at 7:34 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: "Arun Arunachalam (carunach)" <[email-masked]>
Date: Wed, 21 Dec 2016 21:54:48 +0000

Thanks Ben and Gonzalo !

We will consider the suggestion and reference the two RFCs.

Arun

> On Dec 21, 2016, at 4:31 PM, Gonzalo Salgueiro (gsalguei) <[email-masked]> wrote:
>