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

"Ben Campbell" <ben@nostrum.com> Mon, 12 December 2016 22:34 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0C3129DE8; Mon, 12 Dec 2016 14:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level:
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkjkA5aBDoGj; Mon, 12 Dec 2016 14:34:13 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDD2129DE2; Mon, 12 Dec 2016 14:34:13 -0800 (PST)
Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBCMY6EC059530 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Dec 2016 16:34:07 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39]
From: "Ben Campbell" <ben@nostrum.com>
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
Date: Mon, 12 Dec 2016 16:34:06 -0600
Message-ID: <7678F731-160A-4B67-904E-AB420347F951@nostrum.com>
In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C1C689@VOEXM31W.internal.vodafone.com>
References: <36BFA904-FB78-4D63-BA62-B559BA5D700B@nostrum.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8BF0239@VOEXM31W.internal.vodafone.com> <D18D70C3-F434-41F8-8F2F-EE378D4C2C39@nostrum.com> <7D7CAAD4-4534-4053-87B3-73410BF6CF90@att.com> <E81E6C6F-1756-4A0D-8FD7-B50E0865D6C8@nostrum.com> <6FC083A4-5D79-487B-A0F3-291171F6D14C@att.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C1C689@VOEXM31W.internal.vodafone.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_25E17DAB-BD91-4857-8EE6-0ED384D98EE0_="
Embedded-HTML: [{"HTML":[639, 38932], "plain":[226, 13981], "uuid":"1FC0789B-7FCD-495F-BCED-91A47AF3FE45"}]
X-Mailer: MailMate (1.9.6r5310)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/C-sgdCdgmLxiFws5yvpnQJXjb1U>
Cc: Arun Arunachalam <carunach@cisco.com>, "insipid@ietf.org" <insipid@ietf.org>, Gonzalo Salgueiro <gsalguei@cisco.com>, "DOLLY, MARTIN C" <md3135@att.com>, "draft-ietf-insipid-logme-reqs.all@ietf.org" <draft-ietf-insipid-logme-reqs.all@ietf.org>
Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 22:34:20 -0000

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:

> 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:md3135@att.com]
> Sent: 24 November 2016 02:20
> To: Ben Campbell
> Cc: Dawes, Peter, Vodafone Group; Arun Arunachalam; insipid@ietf.org; 
> Gonzalo Salgueiro; draft-ietf-insipid-logme-reqs.all@ietf.org
> 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: md3135@att.com<mailto:md3135@att.com>
>
>
> On Nov 23, 2016, at 9:02 PM, Ben Campbell 
> <ben@nostrum.com<mailto:ben@nostrum.com>> 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: md3135@att.com<mailto:md3135@att.com><mailto:md3135@att.com>
>
>
> On Nov 23, 2016, at 7:34 PM, Ben Campbell 
> <ben@nostrum.com<mailto:ben@nostrum.com><mailto:ben@nostrum.com>> 
> 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