Adam, please see two further suggestions, in-line:

> -----Original Message-----
> From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
> Sent: Friday, February 09, 2018 9:22 AM
> To: Adam Roach
> Cc: The IESG; opsawg@ietf.org; Warren Kumari; Paul Hoffman; draft-mm-wg-
> effect-encr...@ietf.org
> Subject: Re: Adam Roach's No Objection on draft-mm-wg-effect-encrypt-17:
> (with COMMENT)
> 
> Hi Adam,
> 
> Thanks for the additional comments.  We'll discuss in line and make
> updates as appropriate.
> 
... <snip> ... to add a suggestions where needed ...
> > ----------------------------------------------------------------------
> -----
> >
> > §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.
> 
[ACM] 
Since this is the section on SFC, and describing the failure of the 
classifier function [RFC7665], we are talking about the present-day
designs and possible loss of functionality.

I suggest (last phrase, with the entire paragraph included for context):

   There are also mechanisms provided to protect security and privacy.
   In the SFC case, the layer below a network service header can be
   protected with session encryption.  A goal is protecting end-user
   data, while retaining the intended functions of [RFC7665] at 
   the same time.
  


> >
> > ----------------------------------------------------------------------
> -----
> >
> > §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. 
[ACM] 
If you are notified by SMS, what happens next?
Does the SMS suggest that you call customer care to resolve the issue
(which might be less efficient than accessing your account on the web,
and authorizing additional Data Usage) ?

> > 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!
> 
[ACM] Perhaps some re-wording to remove "inconvenience" ?
Suggest:
   ... The customer may need
   to call customer care to find out the reason and/or resolve the issue,
   possibly extending the time needed to restore their network access.

> >
> > ----------------------------------------------------------------------
> -----
> >
<snip>
> 
> >
> 
> Thanks for helping to improve the document.

[ACM] +1

Al

> 
> --
> 
> Best regards,
> Kathleen
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to