Subject: [Stackevo] My notes on https://tools.ietf.org/html/draft-iab-marnew-report-00

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 3 Sep 2017 19:26:09 -0500

Dear StackEvo,

Brian has Natasha and I down to provide an updated Marnew report for
discussion on this week's call.

I went through https://tools.ietf.org/html/draft-iab-marnew-report-00, and
had a bunch of comments (below), but the vast majority are nits. The
biggest changes I proposed were putting paragraphs in Section 7 and Section
8 that said basically "this is what we thought immediately after the
workshop", and that's the outstanding comment I remember when we last
worked on this draft.

The high-order bit on this is that Natasha and the people who commented
have this draft in pretty good shape now. I have better understanding of
the bar for IETF stream docs than for IAB docs, but that's the way it looks
to me.

So, I should also ask - this version is just a name change from
https://tools.ietf.org/html/draft-nrooney-marnew-report-03, and -03 and -02
were only date changes to prevent expiry. Has the IAB, or anyone else,
provided comments since April 4, 2016, when -01 (which contained lots of
changes) was submitted? I likely wouldn't have seen them.

Thanks,

Spencer

--

Nit: in section 2.1.1, "We should not delve into:" shouldn't be an entry in
this list - it should be unbulleted, so it introduces the following bullets.

Nit: this text

 From a recent study [Pew2014
<https://tools.ietf.org/html/draft-iab-marnew-report-00#ref-Pew2014>] 64%
of users said concerns over privacy
  have increased, 67% of mobile internet users would like to do more to
  protect their privacy.

would be better as "have increased, and 67%"

Nit: 'further inforcing the "user first" principle' should be "enforcing"

I don't know what "Users also have certain security expectations from
particular contexts" means - specifically, it seems like I should have
security expectations from particular contexts, but I can't confirm that
because I don't know what kinds of contexts we're talking about ("I need
context").

I'm not sure what

 Technologies which can impact user privacy sometimes do this ignorant
  of the privacy implications or incorrectly assume that the benefits
  users gain from the new technology outweigh the loss of private
  information.

means - part of the problem is that technologies themselves aren't ignorant
of anything. Is

 Implementers sometimes develop technologies which can impact user privacy

  sometimes do this while remaining ignorant
  of the privacy implications of those technologies or incorrectly assuming

  that the benefits that users gain from the new technologies outweigh the

  loss of private information from that new technologies.

what's intended?

Nit: "absued" should be "abused"

In

Some suggested solutions for network management of encrypted traffic
  have suggested "trust models".

uses "suggested" as an adjective and a verb in the same sentence. Perhaps

Some proposed solutions for network management of encrypted traffic
  have suggested "trust models".

This text

  Understanding the extent of "auto click through" may
  help make better decisions for consent requests in the future.

isn't clear about who needs to understand this (I believe "users" is
implicit, but we should say who doesn't understand this now), and "the
extent of" reads to me as "how much", and "what" is also important. Perhaps

  If users understand the implications of "auto click through" more
clearly,

  that understanding may help them make better decisions for consent
requests

  in the future.

In this text,

  Issues with this involve
  trust only being applied on end.

I don't understand what "on end" means. Because I'm an IETF AD, I'd guess

  Issues with this involve
  trust only being applied on endpoints.

but then I'm not sure what the sentence means. Is it

  Issues with this involve ensuring that
  trust can only be applied on endpoints.

so that the issue is avoiding forged trust operations, or something else?

The second sentence in this text,

 o  Latency versus Bandwith: allowing the content provider to indicate
     whether a better bandwidth or lower latency is of greater priority
     and allowing the network to react.  Where this bit resides and how
     to authenticate it would need to be decided.

might be clearer if the first sentence included the actual signaling
mechanism the second sentence refers to, as

 o  Latency versus Bandwith: allowing the content provider to indicate
     with a single bit whether a better bandwidth or lower latency is

     of greater priority
     and allowing the network to react.  Where this bit resides and how
     to authenticate it would need to be decided.

I thought

 o  No network management tools: disabling all network management
     tools from the network and allow the protocols to manage
     congestion alone.

might be clearer if it was

 o  No network management tools: disabling all network management
     tools from the network and relying on end-to-end protocols to manage
     congestion.

This text

  Some workshop attendees agreed that applications
  declaring was quality of service they require was not a good route
  given the lack of success in the past.

wasn't easy to parse. Perhaps

 Some workshop attendees agreed that relying on applications to declare

 the quality of service they require was not a good route, given the

 lack of success with this technique in the past.

?

In this text

  Some workshop attendees suggested
  any exchange of information should be biodirectional,

should probably be

  Some workshop attendees suggested
  any exchange of information should be bi-directional,

("bio-" anything would tell the reader that whatever we're talking about is
alive :-)

This text

  TCP was originally devised to work
  on a specific network model that did not anticipate the high error
  rates and highly variable available bandwidth scenarios experienced
  on modern radio access networks.

would be more accurate if it was

  TCP was originally devised to work
  on a specific network model that did not anticipate the high bandwidth,

  high error
  rates and highly variable available bandwidth scenarios experienced
  on modern radio access networks.

This text had nits in a couple of places:

 Strongly related to content providers, CDNs are understood to be a
  trusted deliver of content and have shown great success in fixed

          deliverer
  networks.  Now traffic is moving more to mobile networks there is a

                ^that
  need to place caches at the edge of the network (e.g. in the Gi LAN

                                                               ^^^^^^
  or the radio network) within the mobile network.  Places caches at

                                                    Placing
  the edge of the mobile network is a solution, but requires standards
  developed by content providers and mobile network operators.  The
  CNDi Working Group [CDNI
<https://tools.ietf.org/html/draft-iab-marnew-report-00#ref-CDNI>] at IETF
aims to allow global CDNs to
  interoperate with mobile CDNs; but this causes huge trust issues for
  the caching of encrypted data between these CDNs.  Some CDNs are
  experimenting with "Keyless SSL" to enable safer storage of content
  without passing private keys to the CDN.  Blind Caching is another
  proposal aimed at caching encrypted content closer to the user and
  managing the authentication at the original content provider servers.

Re: "Gi LAN" above - is that the right way to describe Gi these days? I
thought (without re-reading 3GPP specs I last read more than a decade ago)
Gi was (from Wikipedia) an "IP based interface between the GGSN and a
public data network (PDN) either directly to the Internet or through a WAP
gateway", which doesn't scream "LAN" to me, but I'd bet Natasha knows
someone who could tell us, if no one on StackEvo has an opinion.

In this text,

 At the end of the session the panelists were asked to identify one
  key collaborative work item, these were:

I'd suggest

 At the end of the session each panelist was asked to identify one
  key collaborative work item. Their answers were:

I noticed Chatham House Rule mentioned without a reference at the beginning
of Section 6, so checked to make sure there was a reference on first usage.
There is, but the Section where that usage appears is "1.4.  Use of Note
Well and Charter House Rule", and that should probably be "1.4.  Use of
Note Well and Chatham House Rule", I guess?

In this text,

 Mobile networks are regulated, compliance is mandatory (and can
  result in service license revocation in some nations round the world)
  and can incur costs on the mobile network operator.  Regulation does
  vary geographically.  Some regulations are court orders, others are
  "block lists" of websites such as the Internet Watch Foundation list
  [IWF].  Operators are not expected to decrypt sites, so those
  identified sites which are encrypted will not be blocked.

the last sentence doesn't sound right to me. Was the point more like

Operators are not expected to decrypt sites, so those
  identified sites which are encrypted will not be blocked based on

  content.

? If so, I'd bet there are regulators who tell operators to block encrypted
sites, at least some places on the Internet, but this is far from my
expertise.

"restirctions" should be "restrictions".

In this text,

 These regulations do not always apply to the internet, and the
  internet community is not always aware of their existance.

                                                  existence
  Collectively the internet community can work with GSMA and 3GPP and
  act collectively to alleviate the risk imposed by encrypted traffic

      collaboratively, or just drop one of the "collectively"s
  for lawful intercept.  The suggestion from attendees was that if any
  new technical solutions built should have the ability to be easily

                         ^are
  switched off.

Nit: "exhaustve" should be "exhaustive".

I think Section 7 is valuable to preserve, but the first paragraph needs to
say "this was what we thought would happen immediately after the workshop,
and hasn't been updated to reflect what's happened since then". If we do
that, I'd be fine with leaving the bullets in place. To suggest text:

7.  Requirements and Suggestions for Future Solutions

Note to the reader:
  Based on the invited talks and group discussions throughout the workshop,

  attendees (*** who did actually put this together???***) collected a

  set of requirements and possible solutions that would meet those

  requirements. This list follows, but has not been updated to reflect what

  has happened since the workshop was held, and is not exhaustive.

  Requirements

  (the current list of requirements follows)

In this text, I'd suggest

 o  Flexibility: radio access network qualities vary vastly and
     different network needs in content can be identified, so any new

                       ^ "needs for different content types can be
identified"?
     solution should be flexible to either the network type or content
     type or both.

and, after the list of requirements, I'd suggest

  Note to the reader: A collection of solutions suggested throughout

was also created immediately after the workshop, and is given

   below.  This list of solutions also hasn't been updated to

   reflect what has happened since the workshop, and also isn't exhaustive.

   Solutions

   (the current list of solutions follows)

In this text,

 o  Evolving TCP or evolution on the transport layer: this could take
     a number of forms and some of this work is already existing within
     IETF.  Other suggestions include:

  o  Congestion Control: many attendees cited congestion control as a
     key issue, further analysis, investigation and work could be done
     here.

  o  SPROUT: research at MIT which is a transport protocol for
     interactive applications that desire high throughput and low
     delay.  [SPROUT]

  o  PCC: Performance-oriented Congestion Control: is a new
     architecture that aims for consistent high performance even in
     challenging scenarios.  PCC enpoints observe the connection

                                 ^ endpoints
     between their actions and their known performance, which allows
     them to adapt their actions.  [PCC]

the second, third, and fourth bullets should be sub-bullets under the first
bullet. Next on the list,

 o  CDNs and Caches: placing caches closer to the mobile user or
     making more intelligent CDNs would result in faster content
     delivery and less train on the network.  Related work includes:

  o  Blind Caching: a proposal for caching of encrypted content
     [BLIND_CACHING].

  o  CDN improvements: including keyless SSL and better CDN placement.

should also be a bullet with two sub-bullets under it.

For

     The Base Station holds the
     Radio Resource Controller and scheduler which could provide either
     a place to host solutions or data from the Base Station could help
     in devising new solutions.

I'd suggest

     The Base Station holds the
     Radio Resource Controller and scheduler which could provide
     a place to host solutions, or could provide data that would

     help in devising new solutions that would be hosted elsewhere.

For

 o  Identify traffic types via 5-tuple: information from the 5-tuple
     could provide understanding of the traffic type which network
     management could then be applied.

I'd suggest

 o  Identify traffic types via 5-tuple: information from the 5-tuple
     could provide understanding of the traffic type. Network management

     could then be applied, based on that traffic type.

In this text,

o  Metrics and metric standards: in order to evolve current protocols
     to be best suited to today's networks data is needed on the
     current network situations, protocol deployments, packet traces
     and middlebox behaviour.  Futher than this proper testing and
     debugging on networks could provide great insight for stack
     evolution.

I'd suggest

o  Metrics and metric standards: in order to evolve current protocols
     to be best suited to today's networks, data is needed on the
     current network situations, protocol deployments, packet traces
     and middlebox behaviour.  Proper testing and
     debugging on networks could provide great insight for stack
     evolution.

For this text,

 o  5G: Mobile operator standards bodies are in the process of setting
     the requirements for 5G, requirements for network management could
     be added.

I'd suggest

 o  5G: Mobile operator standards bodies are in the process of setting
     the requirements for 5G. Requirements for network management could
     be included as part of that process.

For

 o  How to do congestion controlling in RAN.

                         ^control

Section 8, "Next Steps", should probably also be put into context. I'd
suggest starting it with

  Note to the reader:

Based on the invited talks and group discussions throughout the workshop,

  attendees (*** again, who did actually put this together???***) collected
a

  set of proposed "Next Steps". This list follows, but has not been updated
to reflect what

  has happened since the workshop was held.

Post-workshop Next Steps:

In addition, Section 8 is pretty dense. I'd suggest breaking the single
paragraph up, something like this:

 The next steps for MaRNEW attendees are to begin work on a select
  list of the above recommended solutions and other suggestions within
  the IETF and within other organisations.  At IETF95 the ACCORD BoF
  will be held which will bring the workshop discussion to the wider
  IETF attendance and select key areas to progress on; these are likely
  to be definitions of the metrics to be collected:

  - more information on the stack evolution ideas and their impact to
network management,

  - Mobile Throughput Guidance evolution,

  - evolution of the Blind Caching work and draft definitions of the "1 bit
for latency / bandwidth tradeoff" idea.

  As identified in the "Better Collaboration" section
  together we need to ensure that both groups continue the positive
  relationship to move these ideas forward into being real and workable
  solutions and both groups need to understand that even though
  collaboration between the operator network and the internet is of
  great importance the item of most importance is the experience and
  security for the users using these services.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 5 Sep 2017 11:50:43 +0200

hi Spencer,

> On 4 Sep 2017, at 02:26, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Dear StackEvo,
> 
> Brian has Natasha and I down to provide an updated Marnew report for discussion on this week's call.
> 
> I went through https://tools.ietf.org/html/draft-iab-marnew-report-00, and had a bunch of comments (below), but the vast majority are nits. The biggest changes I proposed were putting paragraphs in Section 7 and Section 8 that said basically "this is what we thought immediately after the workshop", and that's the outstanding comment I remember when we last worked on this draft.
> 
> The high-order bit on this is that Natasha and the people who commented have this draft in pretty good shape now. I have better understanding of the bar for IETF stream docs than for IAB docs, but that's the way it looks to me.
> 
> So, I should also ask - this version is just a name change from https://tools.ietf.org/html/draft-nrooney-marnew-report-03, and -03 and -02 were only date changes to prevent expiry. Has the IAB, or anyone else, provided comments since April 4, 2016, when -01 (which contained lots of changes) was submitted? I likely wouldn't have seen them.

IIRC (the Mailman archives are empty, and my other old archived mail is stored offline at the moment, so if someone recalls this message and can find it I'd appreciate it), the IAB received comments from Stephen Farrell amounting largely to "this document is too neutral about certain operational practices", which IMO kind of misses the point of a workshop report to report on the discussion at a workshop. I don't recall any other input.

The only additional comment from the Prague stackevo meeting was "correct tense in Next Steps, and remove items overtaken by events" -- the document should report what happened, but it should be current.

Cheers,

Brian

> Thanks,
> 
> Spencer
> 
> --
> 
> Nit: in section 2.1.1, "We should not delve into:" shouldn't be an entry in this list - it should be unbulleted, so it introduces the following bullets.
> 
> Nit: this text
> 
>   From a recent study [Pew2014] 64% of users said concerns over privacy
> I don't know what "Users also have certain security expectations from particular contexts" means - specifically, it seems like I should have security expectations from particular contexts, but I can't confirm that because I don't know what kinds of contexts we're talking about ("I need context").
> 
> I'm not sure what
> 
> means - part of the problem is that technologies themselves aren't ignorant of anything. Is
> 
> isn't clear about who needs to understand this (I believe "users" is implicit, but we should say who doesn't understand this now), and "the extent of" reads to me as "how much", and "what" is also important. Perhaps
> 
>    If users understand the implications of "auto click through" more clearly,
>    that understanding may help them make better decisions for consent requests
>    in the future.
> 
> In this text,
> 
>    Issues with this involve
> might be clearer if the first sentence included the actual signaling mechanism the second sentence refers to, as
> 
> ("bio-" anything would tell the reader that whatever we're talking about is alive :-)
> 
> This text
> 
>    CNDi Working Group [CDNI] at IETF aims to allow global CDNs to
> Re: "Gi LAN" above - is that the right way to describe Gi these days? I thought (without re-reading 3GPP specs I last read more than a decade ago) Gi was (from Wikipedia) an "IP based interface between the GGSN and a public data network (PDN) either directly to the Internet or through a WAP gateway", which doesn't scream "LAN" to me, but I'd bet Natasha knows someone who could tell us, if no one on StackEvo has an opinion.
> 
> In this text,
> 
> I noticed Chatham House Rule mentioned without a reference at the beginning of Section 6, so checked to make sure there was a reference on first usage. There is, but the Section where that usage appears is "1.4.  Use of Note Well and Charter House Rule", and that should probably be "1.4.  Use of Note Well and Chatham House Rule", I guess?
> 
> In this text,
> 
> ? If so, I'd bet there are regulators who tell operators to block encrypted sites, at least some places on the Internet, but this is far from my expertise.
> 
> I think Section 7 is valuable to preserve, but the first paragraph needs to say "this was what we thought would happen immediately after the workshop, and hasn't been updated to reflect what's happened since then". If we do that, I'd be fine with leaving the bullets in place. To suggest text:
> 
>                         ^ "needs for different content types can be identified"?
> the second, third, and fourth bullets should be sub-bullets under the first bullet. Next on the list,
> 
> Section 8, "Next Steps", should probably also be put into context. I'd suggest starting it with
> 
>    Note to the reader:
>    attendees (*** again, who did actually put this together???***) collected a
>    set of proposed "Next Steps". This list follows, but has not been updated to reflect what
> In addition, Section 8 is pretty dense. I'd suggest breaking the single paragraph up, something like this:
> 
>    - more information on the stack evolution ideas and their impact to network management,
>    - evolution of the Blind Caching work and draft definitions of the "1 bit for latency / bandwidth tradeoff" idea.
> 
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 5 Sep 2017 12:21:31 -0500

Hi, Brian,

Thanks for the pre-call feedback. That's always helpful. See inline.

Spencer

On Tue, Sep 5, 2017 at 4:50 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> > I went through https://tools.ietf.org/html/draft-iab-marnew-report-00,
> and had a bunch of comments (below), but the vast majority are nits. The
> https://tools.ietf.org/html/draft-nrooney-marnew-report-03, and -03 and
> -02 were only date changes to prevent expiry. Has the IAB, or anyone else,
> IIRC (the Mailman archives are empty, and my other old archived mail is
> stored offline at the moment, so if someone recalls this message and can
> find it I'd appreciate it), the IAB received comments from Stephen Farrell
> amounting largely to "this document is too neutral about certain
> operational practices", which IMO kind of misses the point of a workshop
> report to report on the discussion at a workshop. I don't recall any other
> input.
>

Stephen's note went to the IAB, MaRNEW program committee, and the draft
personnel (which, I think, is just Natasha), and was sent on 10/27/2016.
The comments are extensive, and they are against -02 of Natasha's
individual Internet-Draft. Please let me know if that doesn't help!

I was remembering the same high-order bit that you were, but there were
other bits that he also commented on. If you think I should, I'll try to
apply my changes, checkpoint, and then work through his, but I'd like
positive confirmation, because the changes won't be small.

> The only additional comment from the Prague stackevo meeting was "correct
> tense in Next Steps, and remove items overtaken by events" -- the document
> should report what happened, but it should be current.
>

Ok, to make sure I understand - as an example, the -00 draft says this in
Next Steps,

   At IETF95 the ACCORD BoF
   will be held which will bring the workshop discussion to the wider
   IETF attendance and select key areas to progress on;

So, should Natasha and I (hi, Natasha!)

   - leave this text - it literally was the planned  next step taken, so
   that's why I'm confused,
   - update this text to say

   At IETF 95 the ACCORD BoF[*]
   was held to bring the workshop discussion to the wider
   IETF attendance and select key areas to progress on;

[*] https://www.ietf.org/proceedings/95/accord.html

   - or remove this item, because that was several IETFs ago, so overtaken
   by events?

Thanks,

Spencer

Cheers,
>
> Brian
>
> > Thanks,
> >
> > Spencer
> >
> > --
> >
> > Nit: in section 2.1.1, "We should not delve into:" shouldn't be an entry
> in this list - it should be unbulleted, so it introduces the following
> bullets.
> >
> > Nit: this text
> >
> > I noticed Chatham House Rule mentioned without a reference at the
> beginning of Section 6, so checked to make sure there was a reference on
> first usage. There is, but the Section where that usage appears is "1.4.
> Use of Note Well and Charter House Rule", and that should probably be
> "1.4.  Use of Note Well and Chatham House Rule", I guess?
> >
> > In this text,
> >
> > ? If so, I'd bet there are regulators who tell operators to block
> encrypted sites, at least some places on the Internet, but this is far from
> my expertise.
> >
> > I think Section 7 is valuable to preserve, but the first paragraph needs
> to say "this was what we thought would happen immediately after the
> workshop, and hasn't been updated to reflect what's happened since then".
> If we do that, I'd be fine with leaving the bullets in place. To suggest
> text:
> >
> >    - evolution of the Blind Caching work and draft definitions of the "1
> bit for latency / bandwidth tradeoff" idea.
> >

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 5 Sep 2017 23:10:39 +0200

> On 5 Sep 2017, at 19:21, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Brian,
> 
> On Tue, Sep 5, 2017 at 4:50 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> hi Spencer,
> 
> 
> 
> Stephen's note went to the IAB, MaRNEW program committee, and the draft personnel (which, I think, is just Natasha), and was sent on 10/27/2016. The comments are extensive, and they are against -02 of Natasha's individual Internet-Draft. Please let me know if that doesn't help!
> 
> I was remembering the same high-order bit that you were, but there were other bits that he also commented on. If you think I should, I'll try to apply my changes, checkpoint, and then work through his, but I'd like positive confirmation, because the changes won't be small.

My take: changes that make this Not A Workshop Report are not useful, all other constructive changes are. (Could you send me a copy of the message so I have it without Becoming A Sysadmin for the evening?)

> Ok, to make sure I understand - as an example, the -00 draft says this in Next Steps,
> 
>    At IETF95 the ACCORD BoF
> 	• leave this text - it literally was the planned  next step taken, so that's why I'm confused,
> 	• update this text to say
> 	• or remove this item, because that was several IETFs ago, so overtaken by events?

Hm. Judgement call. We had an ACCORD BoF, there were... no useful conclusions,but I think it's fine to keep the reference to it, and link to proceedings.

Thanks, cheers,

Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 5 Sep 2017 23:04:36 -0500

Hi, Brian,

My take: changes that make this Not A Workshop Report are not useful, all
other constructive changes are. (Could you send me a copy of the message so
I have it without Becoming A Sysadmin for the evening?)

Will do.

Spencer

Next Steps,
>       • or remove this item, because that was several IETFs ago, so
overtaken by events?

Hm. Judgement call. We had an ACCORD BoF, there were... no useful
conclusions,but I think it's fine to keep the reference to it, and link to
proceedings.

Thanks, cheers,

Brian

> Thanks,
>
> Spencer
>
> Cheers,
>
> Brian
>
> > Thanks,
> >
> > Spencer
> >
> > --
> >
> > Nit: in section 2.1.1, "We should not delve into:" shouldn't be an
entry in this list - it should be unbulleted, so it introduces the
following bullets.
clearly,
requests
> > I think Section 7 is valuable to preserve, but the first paragraph
needs to say "this was what we thought would happen immediately after the
workshop, and hasn't been updated to reflect what's happened since then".
If we do that, I'd be fine with leaving the bullets in place. To suggest
identified"?
suggest starting it with
network management,
> >    - evolution of the Blind Caching work and draft definitions of the
"1 bit for latency / bandwidth tradeoff" idea.