marnew / report Goto Github PK

From SFarrell:

Hi Natasha,

(cc'ing IAB+Marnew w/s TPC 'cause I forget what's the
right list for this;-)

I was prompted to read this, as someone was wondering
what follow up was being followed up. I have a bunch
of comments (below) on this. Happy to chat about 'em
however's best but I think some more work's needed on
the text.

I will note that one fine way to get more work done
is to have >1 author so I'd encourage you to ponder
roping in another victim to help you out with this. (*)

Cheers,
S.

(*) I would usually be happy to help but am currently
on the hook for another one of these kind of documents,
so, sorry, but "no" would be my answer if you asked me
to help out on this one now.

Comments on draft-nrooney-marnew-report-02
SF 20161027

• general: The writing needs improving. I guess this was
  done quite quickly but it needs a thorough editing pass.
  More precision is needed in many places, not all noted
  below.

• general: s/internet/Internet/ :-)

• 1.1: "Others use methods which require them to inspect
  parts of the communication that are encrypted,..." It's
  important that we not use language like that I think, as
  it could be read to imply that we have consensus that
  there are situations when one ought be able to "inspect"
  plaintext when ciphertext is what the endpoint emitted.
  Were it phrased like "methods that currently inspect
  plaintext" that'd be just fine. The current wording,
  however just isn't fine at all. (As there are no such
  "methods" for which we do have consensus.)

• 1.1: Not all networks support some form of legal
  interception. (My home network for example.) That needs to
  be qualified e.g. to say "all licensed-band mobile
  networks" or something.

• 1.3: "Although policy related topics were out of scope
  for this workshop they were infrequently referred to.
  Report readers should be reminded that this workshop did
  not and did not aim to discuss policy or policy
  recommendations." I don't know what that wants to say (and
  the 1st sentence seems broken). IIRC, we did discuss some
  of what I'd call policy issues, but perhaps you mean
  discussion aiming for new or changed or predicted
  legislation or regulation, which is something from which
  we steered clear.

• 1.5: "some of which cannot occur for encrypted
  communications" - I think that deserves more explanation,
  likely later in the document or to one of the w/s papers,
  with a reference from here.

• 2.1: "between the two industries" - I would claim to be
  part of the Internet community but not part of any
  industry. Maybe "communities" is better.

• 2.1: I think it'd be better to not say "ciphertext
  should not be broken" but rather that "encryption applied
  at an endpoint intended to be deciphered at another should
  not be thwarted by a third endpoint decrypting" or
  something like that. (One doesn't "break" ciphertext is
  the issue with the current text.)

• 2.1: "Technical solutions for regulation was not in
  scope." I think what's meant is that "Proposing new
  technical solutions based on presumed future regulations
  was not in scope."

• 2.1.1: last 2 bullets should be sub-bullets

• 2.1.2: I don't know how a middlebox could consider
  itself trusted (as they don't really "consider" much at
  all:-). I think you mean that those boxen have previously
  been trusted to see plaintext maybe, but not sure.

• 2.1.2: "Some needs to improve the radio access network
  quality of service could come from increasing radio access
  network cells ("Base Stations"), but this adds to radio
  pollution; this shows the balancing act when deivising
  radio access network architecture." That's not clear to
  me. Maybe s/increasing/increasing numbers of/ is needed?
  But I don't see how "needs" "come from" deploying more
  things really as that seems backwards.

• 2.3: "Solutions of how to improve delivery of encrypted
  content could affect some of all of the privacy benefits
  that encryption brings." I don't understand that.

• 2.3: "If these technologies are necessary they should be
  opt-in." I'm not sure to what you intend "these" to refer,
  but that sentence is at least oddly placed.

• 2.3: "circumnavigate" - I think you mean "counter"

• 2.3: "Trust models" is a terrible term here as shown
  particularly by the last paragraph. (Which needs edits for
  sure.) I think it'd be clearer to call these '"Hey, just
  trust me" models' maybe. But perhaps there's an accurate
  and non-pejorative term we can find. The fact that some
  proponents might use the term "trust models" does not mean
  the report should similarly sin.

• 3, typo: "to expesnive"

• 3.1: "some which are more beneficial than they are
  controversial" I don't think we can say that without being
  more specific. SPUD for example is clearly controversial.
  Might be easier to just drop that sentence and introduce
  this bit another way.

• 3.1: some terms in scare-quotes need explaining, e.g.
  "Network-to-App," "Network-to-User" and "App-to-Network."
  I'd say add a table defining these.

• 3.1, typo: s/was quality/the quality/

• 3.1.1: using "Trust" in the title isn't good - in fact
  replacing that word wherever possible will help generally.
  (It's a bug-bear of mine - there's only downside to using
  the word "trust" unless one precisely defines who is
  trusting whom for what.)

• 3.1.1: "Authentication in that case could be a key
  design element of any new work, as well as explictness
  rather than the transparent middleboxes used more
  recently." I don't get what's meant there. Maybe you mean
  a belief that authenticated middleboxen might be better,
  but that's pretty controversial (I would debunk it
  anyway:-)

• 3.1.1: "...manages a number of realities." Last I looked
  there was only one reality:-)

• 3.1.1: "Solutions for managing congestion on radio
  networks should involve the base station if possible." I
  don't believe that statement had consensus even in the w/s.
  (It's fine to say that "some folks thought..." for such
  stuff, but we shouldn't give an impression of consensus
  that wasn't present.) And you do say that too, so better
  if the text doesn't contradict itself like that.

• section 4: "The GSMA is in the position to collect this
  data" I think it has so far turned out that this isn't the
  case. Maybe better to say "try collect"?

• section 4: Saying SPUD and ICN "may help" isn't a good
  idea. Better to say that there are some folk who think
  they may help or that those are efforts aiming to help.

• section 5: "DNS and DNS caching cause unpredictable
  results." huh? That's not right. What'd you want to say?

• Section 5: CDNs are trusted for chosen content by
  content owners with cash but not by users (who are unaware
  of the existence of CDNs).

• section 5: "Gi LAN" needs explanation.

• section 5: "Keyless SSL" needs a reference and you need
  -to add "and similar" as that's just one company's name
  for their approach and there are others.

• section 5: "blind caching" needs a reference

• section 5: I don't recall that it's correct to say that
  "one bit" was agreed by even the CDN folk as being a "key"
  "work item." But I may be misremembering, so good to check
  with others.

• section 6: "(and can result..." you're missing that
  non-compliance is what might lead to that.

• Section 6: The IWF is not itself a regulation.

• Section 6: "...if the governments cannot get the
  information..." you need to say that this is information a
  (not the:-) government need and that they have a legal
  right to get it (at least according to themselves).

• Section 6: "These regulations do not always apply to the
  internet,..." - that's wrong. I think you want to say that
  not all of these regs apply to the Internet.

• Section 6: "Collectively the internet community can work
  with GSMA and 3GPP and act collectively to alleviate the
  risk imposed by encrypted traffic for lawful intercept. "
  Eh no. That's plain wrong. (As well as badly stated.) I
  don't believe the Internet community has any consensus to
  help with LI.

• Section 6: "The suggestion from attendees was that if
  any new technical solutions built should have the ability
  to be easily switched off." That assumes that some new
  technical solution (to what?) is needed, which is not
  proven.

• Section 7: I don't think these requirements are well
  enough stated for me to agree they are useful nor that the
  w/s considered them so.

• Section 7: You need more caveats before the set of
  "solutions" bullets, e.g. to say that while these were
  mentioned, there is no implication that they are anywhere
  near agreed, even among the w/s attendees.

• Section 7: LURK had its BofS. While the mailing list is
  still there there is no formal future for it in the IETF
  at the moment. It turned out that when examined in more
  detail, there wasn't consensus for the idea, and more
  downsides became apparent than were considered at the
  w/s.

• Section 8: IETF95 is now in the past.

• Section 8: I'm not aware that the MTG thing is being
  worked on. Is it? Same for the 1-bit stuff.

• I think you should add the list of attendees as an
  appendix and the full list of submissions too. (Just
  names and URLs for the latter.)