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

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

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.

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

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.

Looking at the main parts, clause 4 gives a generalized network scenario where log-me marking is needed to make testing practical, which allows an implementer to determine whether the solution is useful to them. Clause 5 summarizes the functional requirements in three categories: the logged information, the marker itself, and SIP entity behaviour to read/write/update/delete the marker, Also, clause 3 introduces definitions at a network architecture and business layer which, it seems to us, more naturally belong with a description of requirements than with protocol. 
We agree that the requirements and the solution should overlap as little as possible and expect that some of the solution draft can be removed now that the requirements document is clear. The solution document can confine itself to the protocol elements and detailed procedures only.

</reply-1>


<major-issue-2>
The purpose of the draft is not clear to me. I understand it to be requirements for the creation of a protocol mechanism; that is, that it would describe the features of the mechanism, but not the details of how the mechanism works. But many of the requirements seem like requirements on the behavior of network elements (that is, mechanism details). If this draft is to be published as an RFC, I think quite a number of them will need to be rethought. Details in the minor concerns section.

- 5.1, REQ1: This seems more like mechanism than a requirement against the mechanism, in that it states a requirement for specific network element behavior. Isn't the real requirement something along the lines of "The mechanism must allow the endpoint to indicate that it wishes the entire message to be logged"?
Also the MUST seems misplaced as stated; do elements have the option not to log? That seems to be in conflict with typical privacy requirements that suggest log minimization.
also...
- 5.3: Req6 is confusing as worded. It starts off saying things work best if the marker goes end to end, then says not to send it end to end. Please explain why the "responsible" behavior goes against the first sentence. (I think we can all infer the reasoning, but it's better to be explicit.)

-- Req7: This seems like mechanism, not requirements for a mechanism. It stated normative requirements on the behavior of a network element. It seems like that belongs in the mechanism document.

-- Req8: Same as last comment.
also...
-- Req10: Again, this seems like mechanism. I would expect a requirement to say something like "The mechanism must allow for stateless operation."

-- Req11: Mechanism again. I would expect a requirement to be of the form of " a log me indication applies for the duration of a dialog (or a session?).
</major-issue-2>

<reply-2>
If the requirements draft is thought of as a place where key decisions about the mechanism are captured then we think it is broadly consistent except for REQ1, even if some requirements look like part of the protocol solution. Looking at each requirement highlighted in "minor concerns": 

REQ1 captures the decision regarding the format of logged information. We agree that it is too detailed and specific for a requirements document. We can move it to the solutions document and also describe what "logged information" looks like including such things as how the "test identifier" appears in the logged information. Also, the word MUST mandates the given format of information, it does not mandate the logging itself. We propose REQ1 be re-worded as:

"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."

REQ6 could be re-worded as follows: " REQ6: A "log me" marker is most effective if all networks on the signalling 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. A "log me" marker SHOULD be removed at trust domain boundaries to ensure that message logging request is not passed to SIP entitles outside the trust domain. "

We think the value of including REQ7, 8, 10, 11 in the requirements document is that it completes the picture of how SIP entities are impacted. However, we agree that REQ7, 8, 10 could be put into the solutions document. We think REQ11 belongs in the requirements documents because stating that a log begins when a dialog is created and ends when the dialog ends is an important decision that has implications on the details of the solution such as B2BUA behaviour, detecting log-me marking that should not be there (i.e. log-me marking starts to appear mid-dialog, and keeping log-me marking constrained.  
</reply-2>

<minor-issues-replies>
<RFC2119 language>
-2: The usage in this draft does not exactly match RFC2119.  That RFC is about interoperability, not compliance or requirements on a mechanism. 
(That could be more clear in the definitions of the terms in 2119, but it's pretty clear in section 6.). That doesn't mean this draft cannot use 2119 terms, but please edit the boilerplate to describe how you really intend to use them. (I note that this draft does use some 2119 language as described in 2119, but that's what triggered my other comments about describing mechanism rather than requirements.

ANSWER) The point is understood, particularly for REQ9 for example. We can review these and edit the text in section 2 "Conventions Used in this Document" where necessary such as: 
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]. They are used to describe mandatory, recommended and optional requirements to be satisfied by "log-me" marker solution.
</RFC2119 language>


<network boundary>
- 3.1, 2nd paragraph: Is this still part of the definition of network boundary?

ANSWER) no, but it follows on from the previous sentence "A network boundary is significant in this document because manipulation of signaling at the boundary could prevent end-to-end testing or troubleshooting" to explain why a network boundary is a defined concept in this requirements draft. 
</network boundary>


<trust domain>
- 3.2: I assume the "trust domain" is specific to trust for logging purposes. I suggest "Logging trust domain" or "logging domain".

ANSWER) The term "trust domain" is used with the understanding that "trust domain" does not have a fixed meaning throughout all uses and RFCs. RFC 3324 section 2.3 defines "trust domain" for network asserted identity and this definition is re-used by RFC 7316 for a private network indicator. "Trust domain" is used without definition in RFC6404. Before creating the term "logging trust domain" it would be good to be sure that we can't keep the term "trust domain" and define how it applies to log-me marking, it seems more elegant. 
</trust domain>


<dialog>
- 4.3, third bullet: Is "dialog" the correct term here? 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?

ANSWER) Authors intend to say dialog.
</dialog>


<log retrieval policy>
- 5.1, third paragraph: Making policies about log retrieval out of scope seems unfortunate. This draft should have something to say about such policies in the form of privacy requirements on the mechanism. That doesn't mean this draft has to state the policies, but it can require the mechanism to discuss them. (Or can something be referenced from the CLF work?)

ANSWER) Can you please expand why it is unfortunate to not say when and how logs are retrieved. The security requirements say "Logged signaling is privacy-sensitive data, therefore signaling logs MUST NOT be readable by an unauthorized third party.", is this not enough? 
</log retrieval policy>


<REQ9>
-- Req9 seems to have privacy implications that need discussion somewhere. How would a user know logging was requested? Can a user override that?

ANSWER) We propose to add a paragraph (the second paragraph below) to clause 6.2.1 to clarify this point: 

6.2.1.  "Log Me" Marking
   The "log me" marker MUST NOT convey any sensitive information,
   although the "log me" marker will sometimes be inserted because a
   particular device is experiencing problems.
   
   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.

   The presence of a "log me" marker might cause some SIP entities to
   log signaling.  Therefore, this marker MUST be removed at the
   earliest opportunity if it has been incorrectly inserted.

   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.

   Logged signaling is privacy-sensitive data, therefore signaling logs
   MUST NOT be readable by an unauthorized third party.

</REQ9>
<identify-user>


- 6.2.1: Would it make sense to say the marker must not contain information can be used to identify the uer or endpoint device, and that it must not be possible to correlate markers across multiple sessions? 
If not, why not?

ANSWER) It would be fine for us to say that the marker must not contain information can be used to identify the user or endpoint device. 
</identify-user>


<modifying the marker>
-- Does the requirement that the marker must not be modified in transit imply that it must not be possible for it to be modified, or just that participating endpoints must not modify it?

ANSWER) Section 6.2.1 says that debugging configuration MUST NOT be altered in transit, it does not say anything about modifying a log-me marker. Perhaps it would be better if the requirements draft did not say anything configuring entities for logging. 
</modifying the marker>


<protecting-logs>
-- 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.

ANSWER) Section 5.1 says "When and how signaling logs are retrieved is out of scope of this document.", which refers to the act of copying or transferring logged information from the SIP entity that wrote them after logging has finished. The requirement that these logs not be readable by an unauthorized party is slightly different, e.g. perhaps they are encrypted, or perhaps a secure account is needed to log on to the entity that wrote the logged information. We can try to make this distinction stronger.
</protecting-logs>


<section-6.2.2>
- 6.2.2: The previous section stated this more strongly, so this section seems entirely redundant.

ANSWER) Agreed. Rather than deleting 6.2.2 we propose to move the last paragraph of 6.2.1 "Logged signaling is privacy-sensitive data, therefore signaling logs MUST NOT be readable by an unauthorized third party. " to replace the existing text in 6.2.2. In this way, the security section does not lose the distinction between the log-me marker and the logged information. 
</section-6.2.2>


<editorials>
ANSWER) Thanks, we will correct these.
</editorials>
</minor-issues-replies>


> -----Original Message-----
> From: insipid [mailto:[e-mail]] On Behalf Of Ben Campbell
> Sent: 31 October 2016 21:32
> To: [e-mail]; [e-mail]
> Subject: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10
> 
> Hi, this is my initial AD evaluation of draft-ietf-insipid-logme-reqs-10.
> 
> I have some significant concerns about this document, as noted below.
> I'd like to discuss the major concerns before progressing the document.
> 
> Major Concerns:
> 
> - 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.
> 
> - The purpose of the draft is not clear to me. I understand it to be
> requirements for the creation of a protocol mechanism; that is, that it would
> describe the features of the mechanism, but not the details of how the
> mechanism works. But many of the requirements seem like requirements on
> the behavior of network elements (that is, mechanism details). If this draft is
> to be published as an RFC, I think quite a number of them will need to be
> rethought. Details in the minor concerns section.
> 
> Minor Concerns:
> 
> -2: The usage in this draft does not exactly match RFC2119.  That RFC is about
> interoperability, not compliance or requirements on a mechanism.
> (That could be more clear in the definitions of the terms in 2119, but it's
> pretty clear in section 6.). That doesn't mean this draft cannot use 2119
> terms, but please edit the boilerplate to describe how you really intend to
> use them. (I note that this draft does use some 2119 language as described in
> 2119, but that's what triggered my other comments about describing
> mechanism rather than requirements.
> 
> - 3.1, 2nd paragraph: Is this still part of the definition of network boundary?
> 
> - 3.2: I assume the "trust domain" is specific to trust for logging purposes. I
> suggest "Logging trust domain" or "logging domain".
> 
> - 4.3, third bullet: Is "dialog" the correct term here? 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?
> 
> - 5.1, REQ1: This seems more like mechanism than a requirement against the
> mechanism, in that it states a requirement for specific network element
> behavior. Isn't the real requirement something along the lines of "The
> mechanism must allow the endpoint to indicate that it wishes the entire
> message to be logged"?
> 
> Also the MUST seems misplaced as stated; do elements have the option not
> to log? That seems to be in conflict with typical privacy requirements that
> suggest log minimization.
> 
> - 5.1, third paragraph: Making policies about log retrieval out of scope seems
> unfortunate. This draft should have something to say about such policies in
> the form of privacy requirements on the mechanism. That doesn't mean this
> draft has to state the policies, but it can require the mechanism to discuss
> them. (Or can something be referenced from the CLF work?)
> 
> - 5.3: Req6 is confusing as worded. It starts off saying things work best if the
> marker goes end to end, then says not to send it end to end.
> Please explain why the "responsible" behavior goes against the first
> sentence. (I think we can all infer the reasoning, but it's better to be
> explicit.)
> 
> -- Req7: This seems like mechanism, not requirements for a mechanism. It
> stated normative requirements on the behavior of a network element. It
> seems like that belongs in the mechanism document.
> 
> -- Req8: Same as last comment.
> 
> -- Req9 seems to have privacy implications that need discussion somewhere.
> How would a user know logging was requested? Can a user override that?
> 
> -- Req10: Again, this seems like mechanism. I would expect a requirement to
> say something like "The mechanism must allow for stateless operation."
> 
> -- Req11: Mechanism again. I would expect a requirement to be of the form
> of " a log me indication applies for the duration of a dialog (or a session?).
> 
> - 6.2.1: Would it make sense to say the marker must not contain information
> can be used to identify the uer or endpoint device, and that it must not be
> possible to correlate markers across multiple sessions?
> If not, why not?
> 
> -- Does the requirement that the marker must not be modified in transit
> imply that it must not be possible for it to be modified, or just that
> participating endpoints must not modify it?
> 
> -- 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.
> 
> - 6.2.2: The previous section stated this more strongly, so this section seems
> entirely redundant.
> 
> Editorial Comments:
> 
> - Abstact: "... if network or client software is upgraded.":
> s/if/when
> 
> - abstract, paragraph 2:
> I assume this document intends to create requirements on the capabilities of
> a logme indication mechanism, not define how the indicator works. (The
> latter would be solution, not requirements)
> 
> - introduction: " if SIP client software/hardware"
> 
> I suggest "... when SIP client software or hardware"
> 
> -3.1, 2nd paragraph : "prevent the
>     sending network passing on sensitive information"
> s/network passing/network from passing/
> 
> - figure 1: there are lines that don't seem to line up. (e.g. diagonal line from
> top of country Y and from the side of country X, Operator A, SIP phones.
> 
> - 5.3, Req 9: Should the "dialog" be "session"?
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid