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 

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

[Kathleen Moriarty]

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.

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.  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 discover if
there is a network issue.  I'd be embarrassed if I called an
application provider and the issue was the network.  I'd want to rule
out the network and services like DNS prior to making that call.

I know this is one Al wanted to hold firm on and I agree with him from
my experience.

How about the following to make the point more clear for those not
familiar with troubleshooting:

OLD:
Network operators are often the first ones called upon to investigate
application problems (e.g., "my HD video is choppy").

NEW:
Network operators are often the first ones called upon to investigate
application problems (e.g., "my HD video is choppy"), to first rule
out network and network services as a cause for the underlying issue.

I