Hi Adam, Thanks for the additional comments. We'll discuss in line and make updates as appropriate.
On Mon, Feb 5, 2018 at 8:00 PM, Adam Roach <a...@nostrum.com> wrote: > Adam Roach has entered the following ballot position for > draft-mm-wg-effect-encrypt-17: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for all the work that has gone into this document. The framing and tone > is much improved over -10, and the reorganization of section 7 into the rest > of the document helps a lot. I do have a handful of comments. In particular, > I think the omission in section 2.3.4 is very important; however, I > wanted to clear my discuss and trust the sponsoring AD to do the right thing > here rather than re-issuing a different discuss position. Thank you and we'll do our best to address comments. > > --------------------------------------------------------------------------- > > §2.1.2 -- I am surprised that there is so much discussion of fields that are > not generally encrypted in practice (e.g., RTP headers, TCP headers). It may > be worth distinguishing between session-layer, transport-layer and > network-layer security. > > (I think I mentioned this in my initial review, and saw neither a response > nor a > document change in reaction to it.) As a result of your comments and other similar ones, the introduction text was updated to explain that this document is not limited to TLS and that other end to end encryption protocols are considered in this draft. The IPsec OS implementations (NULL authentication) resulting from RFC7258 decisions is one example of an increase in encryption deployment and in this case limiting visibility to a 2-tuple. Breaking down what is used in current operations is a way to understand that impact, hence discussions on visibility used from 5-tuples is discussed in the draft. This section talks about the actual headers used in monitoring, which is at a more detailed level than stating session, transport, or network layer. So we assumed making this additions satisfied your comment at a more detailed level. Would you like to see the layer in addition to the header accessed or an explanation in one section on what is in each layer? I'd just like to understand what you are looking for in this comment to make the document read more clearly. In the last revision, we tried to add in (where it made sense) if a 2-tuple or 5-tuple was enough throughout the document, so that's pretty much the same thing, but I thought was a bit more precise. Or are you just asking for a discussion within this section in particular? Thanks! > > --------------------------------------------------------------------------- > > §2.2.3 -- This section reads like a set of unfinished "notes to self" for the > authors' later use. Minimally, I would suggest restructuring the sentence > fragments in this section into sentences. I will also note that section 2 > indicates that the following sections will discuss both (a) purpose of the > technique, and (b) fields used to achieve this purpose. This section appears > to lack the latter. > We'll fix the sentences, the section looks bad and I'm sorry we somehow didn't catch that. We've been hesitant to make additional changes over what's been requested by reviewers/ADs as it seems to invite more comments, so that may be part of why it wasn't fixed previously. How about the following: "For User Plane Congestion Management (3GPP UPCON) the ability to understand content and manage networks during periods of congestion is th efocus of this work item. Mitigating techniques such as deferred download, off-peak acceleration, and outbound roamers are a few examples of the areas explored in the associated 3GPP documents describing the issues, data utilized in managing congestion, and policy recommendations." Unfortunately, the document relied on contributions and if they didn't come in, we weren't able to make assumptions of what was used as editors. > --------------------------------------------------------------------------- > > §2.2.5: > >> For example, network caching of popular content at a >> location close to the requesting user can improve delivery efficiency >> (both in terms of lower request response times and reduced use of >> International Internet links when content is remotely located), and >> authorized parties acting on their behalf use DPI in combination with >> content distribution networks to determine if they can intervene >> effectively. Caching was first supported in [RFC1945] and continued >> in the recent update of "Hypertext Transfer Protocol (HTTP/1.1): >> Caching" in [RFC7234]. > > The transition from the general case of caching to the specific case of HTTP > proxy caching (and the subsequent change back to the general case) seems > rather abrupt. Consider splitting the HTTP proxy caching out into a separate > paragraph. That makes sense, thanks. Suggestion implemented. > > --------------------------------------------------------------------------- > > §2.2.5: > >> The Enhanced Multimedia Broadcast/ >> Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate >> delivering same stream to different users, using either unicast or >> multicast depending on channel conditions to the user. > > This passage also reads like outline notes rather than a finished document. How about the following: The Enhanced Multimedia Broadcast/Multicast Services (3GPP eMBMS) utilizes trusted edge proxies to facilitate delivering the same stream to different users, using either unicast or multicast depending on channel conditions to the user. Thanks for catching that! > > --------------------------------------------------------------------------- > > §2.2.5: > >> preserving end-to-end security: AMT, for instance, allows CDNs to > > Please expand "AMT". Done, thanks! > > --------------------------------------------------------------------------- > > §2.2.7: > >> A goal is protecting end-user >> data -- but at the same time not making the network inoperable or >> unmanageable. > > I fear this sentence falls back to the hyperbolic tone that plagued version > -10 of this document. I suggest something more along the lines of "...not > forcing changes to the way networks have historically been operated and > managed" or something similar. I'd like Al to weigh in one this change from an operator perspective. To me, this reads like both sides are being weighed equally. He may have another suggestion that works to help with the tone you are looking for, but also acks the impact to operators to further the discussion. > > --------------------------------------------------------------------------- > > §2.3.2: > >> The customer may need >> call customer care to find out the reason, both an inconvenience >> to the customer and additional overhead to the mobile network service >> provider. > > I believe this is false. Please remove this assertion or support it with a > citation. > > To my knowledge, standard operating procedure for mobile networks (based on my > personal experience on two different post-paid US carriers and probably half a > dozen pre-paid non-US carriers) is that users are sent an SMS message > explaining the situation. I think the statement above overstates the > inconvenience to both users and operators, and consequently runs the risk of > causing protocol designers to evaluate the impact incorrectly. I'll wait for Al to weigh in since he works at a major provider, especially since this just says "may". I wouldn't want to weigh in with my anecdotal experience as an end user. I have had to call my provider at times and it is an inconvenience to say the least! > > --------------------------------------------------------------------------- > > §2.3.4: > >> Third parties use >> the inserted information for analytics, customization, advertising, >> to bill the customer, or to selectively allow or block content. > > This is much improved over the previous formulation, but it leaves out a > simple > factual statement that is highly relevant when designers are evaluating the > impact of encryption on this behavior. In fact, I would argue that it leaves > out the *most* notable use of these headers: cross-site user tracking. I > suggest amending the list to something like: > > Third parties use the inserted information for analytics, customization, > advertising, cross-site tracking of users, to bill the customer, or to > selectively allow or block content. Thanks, that's a fair addition. Done! > > --------------------------------------------------------------------------- > > §3.3: > >> encryption approach described below. In most cases, solution have >> been identified to provide encryption while ensuring management > > Nit: "...solutions have..." > Thanks, updated! > > --------------------------------------------------------------------------- > §3.2.2 and §5.1: > > Nit: s/SPAM/spam/g > Done, thanks. > Thanks for helping to improve the document. -- Best regards, Kathleen _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
