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

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 23 Nov 2016 14:59:24 +0000

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:[email-masked]] On Behalf Of Ben Campbell
> Sent: 31 October 2016 21:32
> To: [email-masked]; [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Nov 2016 18:33:39 -0600

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

> -	Passing the log-me marker across SIP entities

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.

Once the solution _is_ built, do they still need that?

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? For example, since this draft directly states 
requirements on SIP network element behavior would you expect the 
solution draft to also do that? If not, what sorts of behavior go here?

I'm pushing on this point because I expect them to come up during the 
IESG review. (Please see the recent IESG statement on support documents: 
https://mailarchive.ietf.org/arch/msg/ietf-announce/EZi3owksw9TT6ym5ZbONHnv-Yl4

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

That seems reasonable. (And it would even be reasonable to mandate that 
CLF be used, as in the original version.

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

The first two sentences seem reasonable statements about mechanism 
requrements. The last sentence is a requirement on network element 
behavior.

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

The first part of Req7 seems reasonable, but the last sentence seems 
like solution. Req 8 seems very much solution--I suspect you intend a 
requirement along the line of "The mechanism must correlate request and 
response log entries"?

Req9: Are you looking for something like "The mechanism SHOULD allow SIP 
intermediary to request logging on behalf of the originating endpoint"?

Req10: "The mechanism should allow stateless behavior for SIP 
intermediaries"?

Req11: "A logging request applies to all requests and responses in the 
dialog"?

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

How about something like the following for the last sentence": "..., 
except that rather than describing interoperability requirements, they 
are used to describe requirements to be satisfied by the "log-me" marker 
solution."

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

Okay

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

On rereading the paragraph, I think it's okay.

>
>
> <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?
>

Is there a requirement for correlating logs across related dialogs, 
similar to the way Session-ID does? This seems required in several 
places (e.g. Req9 mentions a transfer use case.) If so, it would be good 
to explicitly mention it. Stating the logging scope as a "dialog" 
without further comment on related dialogs could be construed to not 
require it.

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

 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.

Would it make sense to say that the log retrieval mechanism is required 
to support certain authorization policies and privacy protections, but 
that otherwise the details are out of scope?

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

That helps, thanks.

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

On reflection, can you meet the intended use cases without identifying a 
device or 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>

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?

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

See my previous comment.

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

Works for me.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 24 Nov 2016 01:08:03 +0000

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]>

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

Ben.

Hello Ben,

Regards,

<major-issue-1>

<reply-1>

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

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? For example, since this draft directly states requirements on SIP network element behavior would you expect the solution draft to also do that? If not, what sorts of behavior go here?

I'm pushing on this point because I expect them to come up during the IESG review. (Please see the recent IESG statement on support documents: https://mailarchive.ietf.org/arch/msg/ietf-announce/EZi3owksw9TT6ym5ZbONHnv-Yl4

</reply-1>

<major-issue-2>

<reply-2>

That seems reasonable. (And it would even be reasonable to mandate that CLF be used, as in the original version.

The first two sentences seem reasonable statements about mechanism requrements. The last sentence is a requirement on network element behavior.

The first part of Req7 seems reasonable, but the last sentence seems like solution. Req 8 seems very much solution--I suspect you intend a requirement along the line of "The mechanism must correlate request and response log entries"?

Req9: Are you looking for something like "The mechanism SHOULD allow SIP intermediary to request logging on behalf of the originating endpoint"?

Req10: "The mechanism should allow stateless behavior for SIP intermediaries"?

Req11: "A logging request applies to all requests and responses in the dialog"?

<minor-issues-replies>
<RFC2119 language>

How about something like the following for the last sentence": "..., except that rather than describing interoperability requirements, they are used to describe requirements to be satisfied by the "log-me" marker solution."

<network boundary>

Okay

<trust domain>

<dialog>

Is there a requirement for correlating logs across related dialogs, similar to the way Session-ID does? This seems required in several places (e.g. Req9 mentions a transfer use case.) If so, it would be good to explicitly mention it. Stating the logging scope as a "dialog" without further comment on related dialogs could be construed to not require it.

<log retrieval policy>

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

Would it make sense to say that the log retrieval mechanism is required to support certain authorization policies and privacy protections, but that otherwise the details are out of scope?

<REQ9>

6.2.1.  "Log Me" Marking

</REQ9>
<identify-user>

That helps, thanks.

On reflection, can you meet the intended use cases without identifying a device or user?

<modifying the marker>

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?

<protecting-logs>

See my previous comment.

<section-6.2.2>

Works for me.

_______________________________________________
insipid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/insipid

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Nov 2016 20:02:44 -0600

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:

> On Nov 23, 2016, at 7:34 PM, Ben Campbell 
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> 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.
>
>
>
> 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".
>
>
>
> solution will be built

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 24 Nov 2016 02:20:12 +0000

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

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.

Ben

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:

Ben.

Hello Ben,

Regards,

<major-issue-1>

<reply-1>

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