Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Kathleen Moriarty]

Thanks for your responses.  Inline responses to EKRs responses.  I
think there were some additional recent on list comments that still
need to be addressed and any adjustments from this discussion.  I just
posted to the datatracker as it didn't seem like we needed to use
github now that there isn't an alternate ballot procedure.

On Mon, Feb 26, 2018 at 1:22 PM, Eric Rescorla  wrote:
> Thanks for the updated draft. Some responses below.
>
>
> On Mon, Feb 19, 2018 at 12:11 PM, Kathleen Moriarty
>  wrote:
>>
>>
>> >
>> > DISCUSS
>> >session encryption that deployed more easily instead of no
>> >encryption.
>> >
>> > I think I understand what you are saying here, but the term
>> > "breakable" seems very unfortunate, especially in the context of this
>> > document. The only such shift I am aware of that has received
>> > acceptance in IETF is one from always requiring fully authenticated
>> > encryption to allowing unauthenticated encryption, which you document
>> > in the next paragraph. I recognize that there are other perspectives
>> > (e.g., those in draft-rhrd) but those are pretty far from IETF
>> > consenus. Accordingly, I think you should remove this sentence.
>>
>> Opportunistic security was well discussed, so that was likely top of
>> mind for you when reading this draft. However there are other areas
>> where the IETF decided breakable encryption was better than none in
>> recent years.  Another adopted and published example is in the mail
>> community.  Deprecating MD5 was deemed to be too hard because of
>> support in a particular library.  We had lengthy discussions about
>> this for RFC7627 (see sect 6.2) and related drafts, now published
>> RFCs.
>
>
> I continue to think that the term "breakable" is very unfortunate here
> (and of course, MD5 isn't breakable "encryption").

Sure, but OS is breakable, and both are not the most secure options
available today (known weaknesses).  This is a big shift in thinking.
Even for ACME, when similar ideas were previously presented, they were
not acceptable because of the industry/IETF desire to preserve
security and ideas of what is acceptable.

>
> It seems to me that there are four areas where one might think that
> compromises ought to be made:
>
> 1. Not deploying comsec at all because it's too hard (you allude to this
> later).
> 2. Not deprecating weak algorithms because they are already deployed
> (the case of MD5 and the like)
> 3. Rolling out unauthenticated or opportunistic encryption.
> 4. Rolling out weak algorithms rather than strong ones.
>
> I agree we do 1-3, but my experience is we try pretty hard to avoid #4, and
> that's how I read "breakable encryption".

There were big arguments around this idea included with the SMTP mail
discussions and some even thought this was a consensus statement from
the OS draft, and it is not.  I personally worked to make sure that
statement was not included as a consensus one as there has not been a
specific consensus call on breakable encryption.  It has been
discussed and has been pretty divided.  4 isn't a matter of rolling
new, but really more of 3, keeping existing and not deprecating.

> It's also generally not easier
> to deploy. I think a better way to phrase this would be to say something
> like:
>
> "Perspectives on encryption paradigms have shifted over time to
> incorporporate
> ease of deployment as a high priority, and balance that against providing
> the
> maximum possible level of security regardless of deployment considerations"
>

I'm fine with this wording suggestion.

>>
>> >motivation outside of privacy and pervasive monitoring that are
>> >driving end-to-end encryption for these content providers.
>> >
>> > This section seems kind of confusing, at least as applied to
>> > HTTP. There are three kinds of cache in HTTP:
>> >
>> > - Reverse proxy caches (the kind CDNs run)
>> > - Explicit forward proxy caches
>> > - "Transparent" intercepting caches
>> >
>> > The first of these move to HTTPS just fine and that's typically how
>> > CDNs do it.  Explicit forward proxy caches are largely going away, but
>> > part of the point of this kind of end-to-end encryption is to hide
>> > data from those caches.
>>
>> Sure, that point was made in the draft and cleared up a little further
>> from Benjamin K's review.  The business risk associated with not
>> controlling your content was more explicitly stated for CDNs who have
>> moved to an e2e approach.
>>
>> Here's the updated sentence:
>>The business risk of losing control of content is a motivation outside
>>of privacy and pervasive monitoring that are driving end-to-end
>>encryption for these content providers.
>
>
>>
>> > Transparent intercepting caches that the user
>> > didn't opt into are a bad thing, so having them go away is a positive.
>>
>> The text says authorized parties, so this is referring to caches where
>> there is an agreement in place for this usage.
>
>

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

Thank you.

-Ekr


On Wed, Feb 28, 2018 at 9:06 AM, Warren Kumari  wrote:

> On Wed, Feb 28, 2018 at 11:49 AM, Eric Rescorla  wrote:
> > No worries. Looking forward to your thoughts on my comments.
> >
>
> Me too! I've created a repo
> (https://github.com/wkumari/effect-encrypt) where I'll be placing the
> new version to all for easier viewing / diffs.
>
> W
>
>
> > -Ekr
> >
> >
> > On Wed, Feb 28, 2018 at 8:00 AM, Kathleen Moriarty
> >  wrote:
> >>
> >> Sorry, I wasn’t able to task switch to editing the document yesterday
> with
> >> other work obligations.
> >>
> >> Best,
> >> Kathleen
> >>
> >> Sent from my mobile device
> >>
> >> On Feb 28, 2018, at 9:45 AM, Eric Rescorla  wrote:
> >>
> >>
> >>
> >> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari 
> wrote:
> >>>
> >>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
> >>>  wrote:
> >>> > Hi, Benoit,
> >>> >
> >>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
> >>> > 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. 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
> >>> >> OPSAWG@ietf.org
> >>> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> > ___
> >>> > OPSAWG mailing list
> >>> > OPSAWG@ietf.org
> >>> > 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 

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Warren Kumari]

On Wed, Feb 28, 2018 at 11:49 AM, Eric Rescorla  wrote:
> No worries. Looking forward to your thoughts on my comments.
>

Me too! I've created a repo
(https://github.com/wkumari/effect-encrypt) where I'll be placing the
new version to all for easier viewing / diffs.

W


> -Ekr
>
>
> On Wed, Feb 28, 2018 at 8:00 AM, Kathleen Moriarty
>  wrote:
>>
>> Sorry, I wasn’t able to task switch to editing the document yesterday with
>> other work obligations.
>>
>> Best,
>> Kathleen
>>
>> Sent from my mobile device
>>
>> On Feb 28, 2018, at 9:45 AM, Eric Rescorla  wrote:
>>
>>
>>
>> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari  wrote:
>>>
>>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>>>  wrote:
>>> > Hi, Benoit,
>>> >
>>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
>>> > 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. 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
>>> >> OPSAWG@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/opsawg
>>> >>
>>> >>
>>> >
>>> >
>>> > ___
>>> > OPSAWG mailing list
>>> > OPSAWG@ietf.org
>>> > 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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

No worries. Looking forward to your thoughts on my comments.

-Ekr


On Wed, Feb 28, 2018 at 8:00 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Sorry, I wasn’t able to task switch to editing the document yesterday with
> other work obligations.
>
> Best,
> Kathleen
>
> Sent from my mobile device
>
> On Feb 28, 2018, at 9:45 AM, Eric Rescorla  wrote:
>
>
>
> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari  wrote:
>
>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>>  wrote:
>> > Hi, Benoit,
>> >
>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
>> 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. 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
>> >> OPSAWG@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/opsawg
>> >>
>> >>
>> >
>> >
>> > ___
>> > OPSAWG mailing list
>> > OPSAWG@ietf.org
>> > 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
>>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Alissa Cooper's Abstain on draft-mm-wg-effect-encrypt-17: (with COMMENT)

[Alissa Cooper]

Hi Kathleen,

> On Feb 22, 2018, at 4:07 PM, Kathleen Moriarty 
>  wrote:
> 
> Hi Alissa,
> 
> I believe this is the last set of comments received that we had left
> to respond.  The next update that will come out shortly following this
> message should address all comments and subsequent discussions
> received to date.

Thanks!

> 
> On Thu, Feb 8, 2018 at 8:26 AM, Alissa Cooper  wrote:
>> Alissa Cooper has entered the following ballot position for
>> draft-mm-wg-effect-encrypt-17: Abstain
>> 
>> 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:
>> --
>> 
>> Many thanks for all the effort that has gone in to addressing all the 
>> comments
>> from the last IESG review and from the community. I find this version to be
>> much improved from the last time the IESG reviewed it.
>> 
>> However, I do not feel that I can support the publication of the document.
>> While the tone has improved in many places and the introduction does a better
>> job of contextualizing the document, the document still contains text in
>> several sections that states service providers' claims about their practices 
>> as
>> facts rather than stating them as claims or presenting the practices in a
>> neutral way. This was a point raised in my previous DISCUSS (I've included my
>> previous DISCUSS ballot text below in full for reference). In the previous
>> review round Warren had invited recommendations for places where the tone or
>> choice of words could be made more neutral or balanced, and I provided many
>> detailed suggestions, but a number of those were not adopted. I also realize
>> that the introduction contains much of the disclaimer text we previously 
>> hashed
>> out to try to address this, but it doesn't contain all of it. So this is 
>> still
>> a major issue for the document, IMO.
> 
> I believe we had responded to the discussion and left off with the
> updates matching the last parts of the discussion.
> 
>> 
>> The document also still extemporizes about future possible impacts, making it
>> hard to come away with a neutral view of their treatment, as I noted in my
>> previous DISCUSS ballot.
>> 
>> I support the DISCUSS position held by Ekr. But given the above I don't think
>> it will be fruitful for me to continue to engage on the details of this
>> document, so I'm abstaining.
>> 
>> I've included below some of the areas that I still find problematic, as well 
>> as
>> some nits.
>> 
>> Problematic areas:
>> 
>> = Section 2.1.2 =
>> 
>> (1)
>> "Network operators are often the first ones called upon to investigate
>>   application problems"
>> 
>> I still contend that without data to back this up, this claim should not be
>> made, especially for the enterprise context.
> 
> This is in section 2.1.2, which is specific to service provider
> networks.  Al responded on this previously from his experience.  

This was also my experience at BT. I don’t think it matches the experience of 
the folks who provide WebEx customer service, for example. But I acknowledge 
that is an enterprise example.

I realize that my last ballot text wasn’t clear on this, but my claim wasn’t 
that this is untrue, but rather that if you actually want the text to sound 
neutral rather than reflective of the biases of the authors, then both 
experiences would need to be reflected, not just one.

> My
> experience having worked at a service provider and having managed/been
> responsible for the security of several large enterprises matches his
> - the service provider is often the first call, especially with the
> cited example.  If there's a perceived issue that's network related,
> you have an SLA with the service provider and they have to assist.
> They will figure out if there is a routing issue, congestion, the
> service is not responding, DDoS, or something else that is happening
> to cause the trouble.  These are all issues that require a little
> network troubleshooting before you point the problem at the
> application.  It's not as easy with an application as you don't always
> have someone you can call.  The service provider may be seeing the
> application issue from multiple customers and may then act on behalf
> of many customers to get in touch with the application provider.
> Getting to the right person at an application provider is typically
> much harder then the initial troubleshooting steps to 

[OPSAWG] Alissa Cooper's Abstain on draft-mm-wg-effect-encrypt-22: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-mm-wg-effect-encrypt-22: Abstain

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 addressing most of my concerns in my previous ballot even though I 
abstained.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Kathleen Moriarty]

Sorry, I wasn’t able to task switch to editing the document yesterday with 
other work obligations.  

Best,
Kathleen 

Sent from my mobile device

> On Feb 28, 2018, at 9:45 AM, Eric Rescorla  wrote:
> 
> 
> 
>> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari  wrote:
>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>>  wrote:
>> > Hi, Benoit,
>> >
>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise  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. 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
>> >> OPSAWG@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/opsawg
>> >>
>> >>
>> >
>> >
>> > ___
>> > OPSAWG mailing list
>> > OPSAWG@ietf.org
>> > 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
> 
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Joel Halpern Direct]

I am having trouble reconciling two of your comments.
In you rlast email you said that this is for "planed communities 
represent the groups of customers peers an geographical and topological 
related information".  Planned communities is presumably a new behavior, 
not existing behavior.


In this email you say that these are "already defined BGP communities".

You reference RFC 4384, which talks about several kinds of communities. 
maybe you intend the regional or national communities mentioned as being 
possible, but not defined, in that document.  This document's 
descriptions do not align well enough with RFC 4384 for me to say.


Let's be clear.  The working group asked for an early review.  The WG 
now has my review, indicating that this document is unclear in multiple 
regards and could use improvement.


It is now up to the WG and the chairs.
Yours,
Joel

On 2/28/18 6:22 AM, li zhenqiang wrote:

Hi Joel,

This is not for one operator, instead it is a common practice. Please 
refer to RFC4384 and comments from Thomas who are from Swisscom.


One clarification for this doc is it is not to introduce any new BGP 
communities but to report the already defined BGP communities related to 
a traffic flow through IPFIX, thus the IPFIX collector can analyze the 
traffic in BGP community granularity without running BGP protocol.


BGP community is a transitive attibute, thus the exporter can report all 
the communities carried in the matching route entry, unless some BGP 
communities are filtered by some routers.


Sure I can add some text in the doc to say the proper processing of the 
exporter, something like what I said in the previous mail, do you think 
it is ok and enough?
  When the exporter, i.e. router, receives the templete to report 
the communities, the exporter gets the information through BGP lookup 
using the corresponding source or destination IP of a traffic flow.


Thank you for your comments.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*From:* Joel M. Halpern 
*Date:* 2018-02-28 10:13
*To:* li zhenqiang ; Dongjie
(Jimmy) ; gen-...@ietf.org

*CC:* draft-ietf-opsawg-ipfix-bgp-community@ietf.org
; opsawg

*Subject:* Re: Genart early review of
draft-ietf-opsawg-ipfix-bgp-community-04
Is this for one operator (still important, but not necessarily for
standardization) or are there several operators who have expressed
interest in this?
Yes, we do proactive standards.  But the IDR group, for example, tends
to be very careful to see if interest is reflected in implementation.
In this case, given that what is proposed is a completely different use
of the BGP communities, I think at least more clarity that this is only
expected to be used for communities that match the purpose, and of how
and why the vendors would implement the router-side logic.
To get back to the points I made in the review:
1) The document needs to be much clearer that it is about new
communities whcih are expected to be defined for this use.  It needs to
be clear if this is expected to be applied to communities put on by
other AS, or only to communities provided by routers of the collecting
AS.  The later leads to understandable configuration.  The former leads
to questions about hos the meaning will be known.
2) The document needs to be clear and explicit about what processing it
is expecting the router to provide, and how much configuration is
needed
to get the right things to happen.
Yours,
Joel
On 2/27/18 8:54 PM, li zhenqiang wrote:
 > Hi Joel,
 >
 > This is Zhenqiang Li from China Mobile. The purpose of this doc
is not
 > to report the well-known communities, but the operator planed
 > communities represent the groups of the customers, peers,
 > the geographical and topological related information as stated in
 > RFC4384, which is a common practice and also used in our field
network.
 >
 > When the exporter, i.e. router, receives the templete to report the
 > communities, the exporter gets the information through BGP lookup
using
 > the corresponding source or destination IP of a traffic flow. The
 > procedure for the exporter to get the community informaiton of a
traffic
 > flow is the same as it gets the AS information.
 >
 > Best Regards,
 > Zhenqiang Li
 >

 > li_zhenqi...@hotmail.com
 >
 > *From:* Joel M. Halpern 
 > *Date:* 2018-02-12 00:37
 > *To:* Dongjie (Jimmy) 

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari  wrote:

> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>  wrote:
> > Hi, Benoit,
> >
> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
> 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. 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
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >>
> >
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > 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
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari  wrote:

> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>  wrote:
> > Hi, Benoit,
> >
> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
> 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.
>

Can you send a link to the Github version? I didn't see a reference?

-Ekr


>
> Confused yet? :-P
>
>
> >
> > 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
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >>
> >
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > 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
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg