Thanks for your response. I am OK with your proposed changes. Warren, I think we're done.
-Ekr On Thu, Mar 15, 2018 at 6:16 PM, Kathleen Moriarty < [email protected]> wrote: > Hi EKR, > > I'll assume you're happy with the previous responses. These are all > new comments and have been responded to and addressed. > > I requested that the updated version be posted pending approval. > Responses inline. > > On Wed, Mar 14, 2018 at 8:36 PM, Eric Rescorla <[email protected]> wrote: > > I have reviewed the new version. Thanks for incorporating my comments. > > > > I have two substantive comment and a bunch of editorial suggestions. LMK > if > > you > > would like me to put this in the tracker. > > > > > > SUBSTANTIVE > > > > for attack traffic, meeting regulatory requirements, or for other > > purposes. The implications for enterprises, who own the data on > > their networks is very different from service providers who may be > > > > I don't believe that this is an accurate characterization of the > > relationship between employees and enterprises. It may be that my > > employer forbids me to access Facebook but that doesn't give them > > ownership of my FB data. Perhaps "enterprises, whose networks are > > often only made accessible for business purposes" > > You are typically subject to monitoring of all traffic from a company > network by policy and a signed agreement at the time of employment (at > least in the US). Many companies exclude financial site access as not > to expose PII, but not social media and sharing platforms as that's an > easy mechanism to exfiltrate data. > > These sites are still accessible, just monitored, so I wouldn't want > to falsely change the text to say the network is only available for > business purposes. I would personally advise people to follow that > practice at work though. > > I made the following edits to consider the outbound access of a user > in the description of data. The original text was focused on the > corporate data and resources. > > "The implications for enterprises, who own the data on their networks > or have explicit agreements that permit monitoring of user traffic is > very different from service providers who may be accessing content > that violates privacy considerations." > Thanks. This seems fine. > > > only the headers exposed for the data-link, network, and transport > > layers. Delving deeper into packets is possible, but there is > > typically a high degree of accuracy from the header information and > > > > I don't believe this is accurate either. Sandvine-type DPI devices are > > certainly intended for SPs. > > The text says, "Delving deeper is possible", so that covers your > example. The text is from Chris Morrow who has quite a bit of > operator experience into what actually happens in service provider > networks. This text akcs that DPI is possible, but states that the > more often used information from packet streams is limited to header > information from link, network, and transport layers. A continued > shift in this direction bodes well for end-to-end. > > No change made here. > OK. > > > > > > > > EDITORIAL > > > > negotiation process resulting in fallback to the use of clear text. > > There has already been documented cases of service providers > > preventing STARTTLS to prevent session encryption negotiation on some > > Nit: have already. > > > Changed, thanks. > > > > > > session to inject a super cookie to enable tracking of users for > > advertisers, also considered an attack. These serves as examples of > > undesirable behavior that could be prevented through upfront > > Nit: serve as > > > Changed, thanks. > > > > > > > > their networks is very different from service providers who may be > > accessing content that violates privacy considerations. > > Additionally, service provider equipment is designed for accessing > > perhaps "in a way that violates" > > > Changed, thanks. > > > > > > > > > > supporting protocols (e.g., DNS, DHCP), network and transport (e.g., > > IP, TCP), and some higher layer protocols (e.g., RTP, RTCP). > > Troubleshooting will move closer to the endpoint with increased > > They don't do HTTP inspection? > > > > This is again from Chris Morrow and the statement says generally > limited to supporting protocols. That's meant to mean these are the > most common. It doesn't exclude anything with that wording IMO. This > does align with my experience and what we've heard. The loudest > complaint on HTTP was redirect abilities to let customers know why > their access isn't allowed or for other notifications for non-SMS > users. > OK. > > > > > > > A gap exists for vendors where built-in diagnostics and > > serviceability is not adequate to provide detailed logging and > > debugging capabilities that, when possible, can access cleartext > > Nit: "are not" > > > > Changed, thanks. > > > > > > > debugging capabilities that, when possible, can access cleartext > > network parameters. In addition to traditional logging and debugging > > methods, packet tracing and inspection along the service path > > I think you've got some sort of agreement problem here. It's not the > > capabilities that can access plaintext. > > > > Changed, thanks. > A gap exists for vendors where built-in diagnostics and serviceability > are not adequate to provide detailed logging and debugging > capabilities that, when possible, could be accessed with cleartext > network parameters. Totally, I was just trying to fix the text so it was clearer. > > > > > > filters content based on a blacklist of sites or based on the user's > > pre-defined profile (e.g. for age sensitive content). Although > > filtering can be done by many methods, one commonly used method > > Nit: "e.g.," > > > Fixed, thanks. > > > > > > > encryption that prevents monitoring via interception, while providing > > forward secrecy. > > This text is unobjectionable but perhaps not maximally clear. Perhaps: > > > > "A number of these tools provide passive decryption by providing the > > monitoring device with the server's private key. The move to increased > use > > of of forward-secret key exchange mechanism impacts the use of these > > techniques". > > > Changed, thanks. > > > > > > > more effective at preventing malware from entering the network. Some > > enterprises may be more aggessive in their filtering and monitoring > > policy, causing undesirable outcomes. Web filtering solutions > > Nit: aggressive. > > Fixed, thanks. > > > > > > > > encrypted. Multiplexed formats (such as HTTP/2 and QUIC) <xref > > target="QUIC"></xref> may however incorporate several application > > streams over one connection, which makes the bitrate/pacing no longer > > Something went wrong with your reference here. > > > > > Fixed, thanks. Editor issue and I thought I had caught all of them > previously. > > > > > user IP flows, deploying them would require enhancing them with > > tunnel translation, tunnel management functions etc.. > > Nit: extra period > > > > > Fixed, thanks. > > > > > Society, "The Security Impact of HTTPS Interception", > > 2017. > > You seem to have lost the authors names here. > > > Fixed, thanks. > > > Best regards, > Kathleen > > > > > On Wed, Mar 14, 2018 at 8:04 AM, Warren Kumari <[email protected]> > wrote: > >> > >> > >> On Wed, Mar 14, 2018 at 10:12 AM Eric Rescorla <[email protected]> wrote: > >>> > >>> Hi Warren, > >>> > >>> I am on travel today, but I expect to read this today or Friday. Can > you > >>> give me until Saturday? > >> > >> > >> Sure. > >> W > >> > >>> > >>> Thanks, > >>> -Ekr > >>> > >>> > >>> On Wed, Mar 14, 2018 at 7:07 AM, Warren Kumari <[email protected]> > wrote: > >>>> > >>>> EKR, > >>>> I'm planning on clicking the "This document is approved" button before > >>>> the IETF101 meeting unless I hear a clear signal that there is > >>>> something that you *cannot* live with. > >>>> > >>>> Thank you again for your Abstain and all of your comments on the > >>>> document, > >>>> W > >>>> > >>>> On Mon, Mar 5, 2018 at 10:58 AM, Warren Kumari <[email protected]> > >>>> wrote: > >>>> > On Wed, Feb 28, 2018 at 9:45 AM, Eric Rescorla <[email protected]> > wrote: > >>>> >> > >>>> >> > >>>> >> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari <[email protected] > > > >>>> >> wrote: > >>>> >>> > >>>> >>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF > >>>> >>> <[email protected]> wrote: > >>>> >>> > Hi, Benoit, > >>>> >>> > > >>>> >>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise < > [email protected]> > >>>> >>> > wrote: > >>>> >>> >> > >>>> >>> >> The way I see it, we're going to fix comments forever. > >>>> >>> > > >>>> >>> > > >>>> >>> > Right. But my concern was that the text that we're reading for > an > >>>> >>> > up/down > >>>> >>> > vote can change after we read it, so I should be tracking the > >>>> >>> > proposed > >>>> >>> > text > >>>> >>> > changes. > >>>> >>> > >>>> >>> [ Updating in the middle of the thread as this seems the logical > >>>> >>> entry > >>>> >>> point ] > >>>> >>> > >>>> >>> ... so, we are not updating the current version (we wanted 7 days > >>>> >>> for > >>>> >>> people to read it), and so will be (I believe) balloting on that > -- > >>>> >>> but, just like any other document we ballot on, the RAD will pay > >>>> >>> attention to comments received and "Do the right thing". > >>>> >>> > >>>> >>> I believe that EKRs comments are helpful, and Kathleen hopes to > >>>> >>> address / incorporate them before the call. I will be putting both > >>>> >>> the > >>>> >>> current (being balloted on) and updated version in GitHub (for a > >>>> >>> friendly web enabled diff) so that people can see what the final > >>>> >>> version will actually look like. > >>>> >>> So, I guess we are formally balloting (unless the DISCUSS is > >>>> >>> cleared) > >>>> >>> on the text as written (-22), but with an understanding that the > AD > >>>> >>> will make it look like the version in GitHub before taking off the > >>>> >>> Approved, Revised ID needed / AD follow-up flag. > >>>> >>> > >>>> >>> Confused yet? :-P > >>>> >> > >>>> >> > >>>> >> Hi Warren, > >>>> >> > >>>> >> Thanks for this note. > >>>> >> > >>>> >> It's too bad that we aren't able to see the proposed revisions at > >>>> >> this > >>>> >> point, but I appreciate your commitment to working through the > >>>> >> remaining issues, and I think we should be able to reach a > >>>> >> satisfactory resolution. > >>>> > > >>>> > I appreciate your Abstain, but, as mentioned, I'm committed to > making > >>>> > sure that the right thing happens here - a new version of the > document > >>>> > (-24) was posted on Friday; I believe that it is now acceptable, and > >>>> > Paul (the document shepherd) also kindly looked through your > comments > >>>> > and the changes and thinks it's OK. > >>>> > > >>>> > I'm sure that you are tired of this by now, but please take a look > at > >>>> > the diffs (stuffed in GitHub > >>>> > > >>>> > (https://github.com/wkumari/effect-encrypt/commit/ > 974db6cb13faecbf5b1704c1da580b320843d0b3) > >>>> > or on the IETF site > >>>> > > >>>> > (https://www.ietf.org/rfcdiff?url1=draft-mm-wg-effect- > encrypt-22&url2=draft-mm-wg-effect-encrypt-24) > >>>> > and let mw know if the document is something you can live with... > >>>> > > >>>> > W > >>>> > > >>>> > > >>>> >> In the interest of not forcing everyone to > >>>> >> read the document by tomorrow, I'm going to change my ballot to > >>>> >> Abstain. > >>>> >> > >>>> >> Best, > >>>> >> -Ekr > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > > >>>> >>> > That doesn't seem up/down. It seems like every other draft I've > >>>> >>> > balloted > >>>> >>> > on > >>>> >>> > as an AD :-) > >>>> >>> > > >>>> >>> > >>>> >>> Indeed. > >>>> >>> W > >>>> >>> > >>>> >>> > Spencer > >>>> >>> > > >>>> >>> >> > >>>> >>> >> And we need to resolve this one before the current ADs step > down. > >>>> >>> >> > >>>> >>> >> Regards, Benoit > >>>> >>> >> > >>>> >>> >> This may not be my week, when it comes to comprehension. At > >>>> >>> >> least, I'm > >>>> >>> >> 0 > >>>> >>> >> for 2 so far today. > >>>> >>> >> > >>>> >>> >> Are we still tuning text in this draft? > >>>> >>> >> > >>>> >>> >> https://www.ietf.org/standards/process/iesg-ballots/ says that > >>>> >>> >> the > >>>> >>> >> alternate balloting procedure is an up/down vote - we either > >>>> >>> >> agree to > >>>> >>> >> publish, or agree to send a document off for rework. > >>>> >>> >> > >>>> >>> >> If we're still resolving comments, one can imagine that we'd > get > >>>> >>> >> to a > >>>> >>> >> one-Discuss situation, or even no Discusses, and wouldn't be > >>>> >>> >> doing an > >>>> >>> >> Alternate Ballot on Thursday. > >>>> >>> >> > >>>> >>> >> I don't object to resolving comments (actually, I find that > >>>> >>> >> lovely), > >>>> >>> >> but I > >>>> >>> >> don't know what we're doing. > >>>> >>> >> > >>>> >>> >> I've never seen the alternate balloting procedure executed > >>>> >>> >> (either as > >>>> >>> >> IESG > >>>> >>> >> scribe or as an IESG member), so maybe I don't get it, and > other > >>>> >>> >> people > >>>> >>> >> have > >>>> >>> >> different expectations. > >>>> >>> >> > >>>> >>> >> Spencer > >>>> >>> >> > >>>> >>> >> > >>>> >>> >> _______________________________________________ > >>>> >>> >> OPSAWG mailing list > >>>> >>> >> [email protected] > >>>> >>> >> https://www.ietf.org/mailman/listinfo/opsawg > >>>> >>> >> > >>>> >>> >> > >>>> >>> > > >>>> >>> > > >>>> >>> > _______________________________________________ > >>>> >>> > OPSAWG mailing list > >>>> >>> > [email protected] > >>>> >>> > https://www.ietf.org/mailman/listinfo/opsawg > >>>> >>> > > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> -- > >>>> >>> I don't think the execution is relevant when it was obviously a > bad > >>>> >>> idea in the first place. > >>>> >>> This is like putting rabid weasels in your pants, and later > >>>> >>> expressing > >>>> >>> regret at having chosen those particular rabid weasels and that > pair > >>>> >>> of pants. > >>>> >>> ---maf > >>>> >> > >>>> >> > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > I don't think the execution is relevant when it was obviously a bad > >>>> > idea in the first place. > >>>> > This is like putting rabid weasels in your pants, and later > expressing > >>>> > regret at having chosen those particular rabid weasels and that pair > >>>> > of pants. > >>>> > ---maf > >>>> > >>>> > >>>> > >>>> -- > >>>> I don't think the execution is relevant when it was obviously a bad > >>>> idea in the first place. > >>>> This is like putting rabid weasels in your pants, and later expressing > >>>> regret at having chosen those particular rabid weasels and that pair > >>>> of pants. > >>>> ---maf > >>> > >>> > >> -- > >> I don't think the execution is relevant when it was obviously a bad idea > >> in the first place. > >> This is like putting rabid weasels in your pants, and later expressing > >> regret at having chosen those particular rabid weasels and that pair of > >> pants. > >> ---maf > > > > > > > > -- > > Best regards, > Kathleen >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
