Re: [hrpc] review of draft-irtf-hrpc-research-00

[Niels ten Oever <[e-mail]>]

Dear Stephen,

Thanks a lot for this extensive review! I hope you (and others) will
allow us some time to give it the attention it deserves, I hope to be
coming back with a full response at the beginning of next week.

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4
                   678B 08B5 A0F2 636D 68E9

On 09/22/2016 10:46 PM, avri doria wrote:
> Hi,
> 
> Stephen, thanks for this review.  Just wanted to give a quick ack, but
> indicate that I am still working my way through it and looking forward
> to the authors' responses and any list discussion that may occur on some
> of the points that were made in this review.
> 
> At this point, are there any other reviews on the -00 we should be
> waiting for?
> 
> Thanks
> 
> avri
> 
> 
> On 22-Sep-16 08:33, Stephen Farrell wrote:
>> Hiya,
>>
>> I spent a bit of time reviewing this finally.
>>
>> Overall, I think this is a fine piece of work and I look
>> forward to it becoming an RFC. I don't think it's nearly ready
>> yet though, there's a lot to fix. (But see #1 below for a
>> suggested short-cut.)
>>
>> Cheers,
>> S.
>>
>> General, and, I think, important to handle...
>>
>> (1) What kind of consensus are we aiming for here?
>>
>> I'm not sure if this would be better off aiming to be a
>> document that has RG consensus or not. There's a lot of fine
>> text here, but there's also quite a few instances of text for
>> which I think it may be quite hard to establish RG consensus,
>> and where that may take some time and draft iterations.
>> (You'll see some examples in my specific conments.) Clearly,
>> processing the document aiming for RG consensus is an option,
>> and maybe the default option, but I wondered if it'd also be an
>> option to proceed more quickly with this documenting the
>> author's research and opinions/conclusions (and not necessarily
>> RG consensus) and to then later try to extract an updated
>> version of the guidlines/questionnaire into a separate RFC
>> aiming for RG consensus. I'm not arguing strongly for that
>> latter plan but just wanted to ask in case it helps the RG (and
>> Avri who I guess will have the fun of figuring this out:-).
>>
>> (2) Length and structure for protocol developers.
>>
>> I think this is too long to be very useful for protocol
>> developers.  I doubt many of them will wade through 40+ pages
>> to get to the bit that's really aimed at them. (And which
>> pretty much needs a total re-write.) The plan mentioned in #1
>> might help there I guess but another idea might be to move
>> section 5.3.2 to the front and make a lot of the rest of the
>> text into subsequent explanatory material and/or appendices.
>>
>> (3) What architecture do you mean?
>>
>> There are 25 lines that mention the term architecture in the
>> draft and I'm not at all sure the term is used to mean the same
>> thing throughout.  I'm also not sure that there is an accepted
>> thing that is "the one true Internet architecture" that has
>> IETF consensus but you seem to me to be assuming that there is
>> such a beast. Is this just a language issue or a deep(er)
>> problem?  I'm not sure, but eliminating references to the
>> Internet architecture where possible would I think help.  See
>> some of the specific comments below, but I'd recommend a pass
>> over the document to check how this term is used as well.  (To
>> try head off some lines of debate that might follow from this
>> comment, I do think there are aspects of Internet architecture
>> for which we do have IETF consensus, but I don't think the IETF
>> has consensus on any one way in which to put all those together
>> into something that'd be rightly termed the (or an) Internet
>> architecture. I think RFC1958 section 2.1 supports that
>> position btw.)
>>
>> (4) What does "=" mean here?
>>
>> In section 2 and later (in 5.2.2) you have diagrams with
>> bracketed terms on the left, then "=" and then another term on
>> the right. I just don't get what you mean by that "=" sign. You
>> say "combine" and "makes up" but frankly I don't get it, even
>> though I was in some of the meetings where those pictures were
>> presented.  E.g. in section 2, I don't get how to combine
>> authenticity and anonymity in any useful sense, as those are
>> mostly in conflict. And the 2nd picture in section 2 has
>> connectivity on the RHS, which you defined as being an "extent"
>> and none of the things on the LHS seem to reflect that at all.
>> While those pictures may well have been ok for use in
>> presentations, I'm less happy that they're useful in an RFC.
>> So, what does "=" mean? Can you actually define that relation?
>> (Apologies if I'm being all "techie" and anal here, but I
>> really don't get it, honest;-)
>>
>> (5) The DDoS discussion is still wrong.
>>
>> I think the discussion of DDoS in section 5.2.11 (see below for
>> specifics) is not good enough and that section needs to be
>> re-written or mostly deleted. (Not all list discussions need to
>> end up with a section in the document.) It may be the case that
>> what is needed is some discussion of forms of protest using the
>> Internet, but that I think would better be the topic for
>> another document, if soeone has the energy/interest. (That
>> could be interesting too!) For this document, if it is aimed at
>> the IETF audience, the current text is not useful as it ends up
>> as a (controversial) NOOP - "don't enable DoS" is already in
>> RFC3552 since 2003.
>>
>> (6) The questionnaire is not good enough.
>>
>> 5.3.2.x.y: Please go through these questions yourself (for some
>> protocol) and write down answers and see then what you think of
>> the questions.  I think a number of these questions will not
>> produce meaningful answers in any real attempt at using them.
>> I also think that someone who is not an author and who is
>> developing a new protocol needs to have gone through the
>> exercise at least once before we should publish this document
>> as any RFC. It is far too easy to ask unanswerable or
>> non-useful questions otherwise.
>>
>> (7) Missing introductory text.
>>
>> I think there's a missing bit of explanatory text about rights
>> in general that'd help some more IETF-oriented readers.  As I
>> understand it, in HR all rights are contingent in the sense
>> that governments are expected to balance competing rights in
>> all cases. So e.g. even though we have a right to life,
>> governments can legislate for capital punishment and still
>> consider themselves signed up to the UDHR. I think this is
>> worth noting, as for example, it means that we do not
>> necessarily want to enshrine all the fine concepts on which the
>> IETF has consensus as human rights, in particular, claiming
>> that one had a right to encrypt could as a side-effect allow
>> some governments to claim that they had a right to limit one's
>> knowledge of mathematics, if that is claimed to compete with
>> other rights (e.g. to safety). I'm not sure if this is the
>> right HRPC document to capture that, but it was a surprise for
>> me when I first found that out, so it may be worth adding a bit
>> of text explaining basic rights concepts like that here or
>> somewhere else.
>>
>> Specific comments (without reference to importance:-)
>>
>> Note: I'm not quite sure why, but I read this through and
>> commented as if it were a PhD thesis, which is a bit more
>> stringent that e.g. IESG evaluation. Apologies if that seems
>> like nitpicking, but I think given the possibly political
>> (ab)uses to which this RFC could be put, and since we might
>> effectively kill the impact of the RG if we do this first RFC
>> badly, we might be better off to take that approach. I'm
>> willing to believe that I'm being too nit-picky though:-)
>>
>> abstract: These ought not have references and I think is too
>> long.  I'd suggest keeping the 2nd para (minus the reference)
>> and move the rest to the intro.
>>
>> intro, p3: How do you know that "open, secure and reliable" are
>> necessary conditions here? I think you're likely correct, but
>> I'm not sure that claim is justified in the document or in the
>> references.
>>
>> intro, p3: "The Internet aims to be a global network of
>> networks that provides unfettered connectivity to all users at
>> all times and for any content [RFC1958]. " The "aims to be"
>> there seems odd, and I don't see where 1958 says "at all times"
>> which seems to me overstated.
>>
>> intro, p3: "One could even argue that the Internet is not only
>> an enabler of human rights, but that human rights lie at the
>> basis of, and are ingrained in, the architecture of the
>> network." Sure one could argue that but is that claimed as an
>> RG consensus? And you're assuming that there is one true
>> Internet architecture there I think, which is problematic.
>>
>> intro, p3: "By doing so, the IETF enabled the manifestation of
>> the right to privacy, through the Internet's architecture." I
>> think this shows a misconception of the IETF's role, at least
>> as I see it. I don't believe that the IETF controls the
>> Internet's architecture in the sense implied here. If you'd
>> said "through it's protocol design processes" at the end
>> instead, then I think that'd be better. And saying "Enabled"
>> makes it sound like a done-deal and we can all go home, which
>> strikes me as pretty optimistic;-)
>>
>> intro, p3, "Openness of communications of the technical design"
>> what does that mean? And how does it "foster freedom of
>> communication"?  I don't get the argument here.
>>
>> intro, p3, "galvanize" is overstated and the IETF doesn't
>> "ensure" what happens in the network, but only in the protocols
>> we define - what implementers and operators do with that is
>> really up to them and not the IETF. That's an important
>> distinction that's mixed up in a few places in the document,
>> including in the next sentence - if the IRTF produces this RFC,
>> that's great and will help to ensure better realisation of HR
>> issues, but the existence of the RFC itself will not ensure
>> anything.
>>
>> section 2: "unfettered" - while I myself do like that term, I
>> think following the approach from RFC 4084 which you quote here
>> would be a good general approach for this entire document.
>> 4084 section 1.2 says that it intentionally avoide pejorative
>> terms so as to increase the likelihood that operators will pay
>> attention. I think following that guidance in this document
>> would be good. Most of the text is actually fine in this
>> respect, but an editing pass based on a review from some (as
>> yet uninvolved) protocol developers would be a good thing.  For
>> example, some of the references to companies and products later
>> on might raise hackles in a way that'd be counter productive.
>> Anyway, 4084 does not use the term unfettered at all so better
>> to not say that here.
>>
>> section 2, and elsewhere: I think the use of the term anonymity
>> is wrong in almost all cases in this document. While it is the
>> case that users (and non-technical folk in general, including
>> law makers) may talk about anonymity, I think there are few to
>> zero technical folks who think that anonymity is achievable at
>> any scale today. Tor may be the closest we get, but it's not at
>> all clear to me that anonymity is really a requirement or a
>> goal for almost all protocol designers almost all of the time.
>> I do think we should consider "being hard to track" and similar
>> as requirements/goals but that's different and I'm not sure we
>> even have that good an idea about all the trade-offs that are
>> involved here. I'd recommend checking every time you use this
>> tern, and getting rid of most of them.  (Will try to point out
>> the ones I think are problematic below.) Note that the 4949
>> definition is probably ok(ish:-) but once there are muliple
>> protocols involved things become very unclear and in real
>> networks, there's almost always someone somewhere who can
>> identify (or re-identify) a person, host or bit of s/w and that
>> context seems to be missing here when you use the term.
>>
>> 2, Defining connectivity as an "extent" is interesting. I'm not
>> sure if it's precise enough though, e.g.,  what'd "twice better
>> connectivity" mean? Not sure what to suggest but I do think
>> you're right to not define it as binary. Maybe refer to RFC4084
>> here again for some different types of connectivity?
>>
>> 2, "content-agnosticism" - hmm, that seems a bit broken to me
>> as a definition, it is ok to treat delay intolerant traffic
>> differently and we do want that sometimes. "Identically" seems
>> too strong, but I'm not sure what better definition to use
>> without getting into an essay about net neutrality and similar
>> things that I don't know much about;-)
>>
>> 2, "end-to-end" - I much prefer to refer to this as an argument
>> and not a principle. You'll get different opinions on that
>> though:-)
>>
>> 2, "Internet censorship" - I think this definition is too broad
>> and could even be read to discourage data minimisation.  It
>> seems to be missing the concept that the censor is acting
>> without the agreement of the endpoints, but agreement/consent
>> is such a slippy concept on the Internet maybe that'd be a bad
>> idea. Anyway, this seems to broad to me fwiw.
>>
>> 2, "Internet Standards as an Arena for Conflict"... eh...
>> What? That's not a term to define, it's an argument for over
>> beer! I think you need to delete that from this section. If you
>> want to include the text somewhere then find a better way to do
>> that I'd say. (But I'd still then ask: where is the principle
>> of constant change defined for all time? :-)
>>
>> 2, "i18n" - I think you're wrong that "Many protocols..." don't
>> support i18n. It's for sure true that a bunch don't do this
>> well and ought, but "many" seems overstated. Did you count
>> them? (Note that for many binary protocols i18n isn't very
>> relevant at all, if one assume that i18n is mostly important
>> for end-users and less so for developers or bigger operators.)
>>
>> 2, "Open Standards Conform" - what? That's not a term to
>> define. I think you also say this elsewhere so deleting this
>> would be right. And what's RFC2606 got to do with it?
>>
>> 2, "Openness" - I think this is just wrong and am not sure what
>> you even want to define. You cannot for example have free
>> access to hosts in my home network, no matter how openly you
>> ask:-) If you want to define openness, then I think it'd have
>> to be about processes and not access to hosts.
>>
>> 2, "permissionless innovation" is not all about new protocols.
>> It's also about using existing protocols in new ways without
>> having to ask. Not all such uses are usefully described as new
>> protocols.
>>
>> 2, "Privacy" - I think adding some references to the HR and
>> legal literature about privacy could help the more technical
>> readers here.
>>
>> 2, reliable, resiliance and robustness - I'm surprised there're
>> no references for the first two and puzzled by the references
>> for the 3rd. There also seem to be very few reference to these
>> later, which makes it odd to find them here. I wonder if the
>> formalism you're using (introduced at the end of section 2) has
>> caused you to shoe-horn in definitions of these?
>>
>> 2, scalable - it's often a challenge in proocol design to
>> ensure that a protocol scales down as well as up, in the sense
>> of working well for smaller networks/deployments.  Might be
>> worth pointing that out as it's relevant here when one
>> considers designing new protocols potentially putting too much
>> emphasis on the requirements of only bigger operators (who are
>> in the room).
>>
>> 2, stateless - is used exactly once later, and stateful is not
>> used at all later - do you really need this here? (Just define
>> it when used, but I think protocol developers will get the
>> meaning anyway.) You could also say that retaining state has
>> potential privacy impact, which may not be so obvious. (That
>> retaining state impacts on other protocol features such as
>> hard-reboot is fairly well understood I think.)
>>
>> 2, "Strong encryption / cryptography" I don't think this is
>> needed or useful - why is it here? I think the IETF community
>> know this already, is it useful for some other readership?  If
>> so who? (Since I'm not sure it'd be that useful for any
>> readership.)
>>
>> 2, "transparent" - I don't like this definition which I think
>> is not actually definining the term in the sense in which you
>> use it in this document. As you actually use the term, it is
>> mostly about processes, which is not what RFC2775 is about. In
>> fact, I think you're actually using the term in it's normal
>> English usage and don't really need a specific definition.
>> (Though I didn't check all uses of the term.)
>>
>> 2, " The combination of reliability, confidentiality,
>> integrity, anonymity, and authenticity is what makes up
>> security on the Internet." No. That is just wrong. For example,
>> that list omits DoS resilience, bugs (and protocol flaws) that
>> cause problems like heartbleed, and I think, much else besides.
>> I'm not sure how to fix this. (But see my general question wrt
>> "=" as used here.)
>>
>> section 4: I don't accept that "protocols are politics by other
>> means" - if I develop a way for two computers to interact in my
>> (non-existent as it happens:-) basement, that is not politics.
>> If I publish an academic paper on a faster way to do ECDH
>> that's not politics.  I know it's a quote, but I don't think
>> you ought present that quote in that way (reading IMO as if it
>> were an RG consensus statement) without qualification.  The
>> relevant qualification I think is tricky to formulate but has
>> something to do with broad deployment or with deployment at
>> some technical choke point that offers significant control to
>> someone.
>>
>> 4: I don't get the "values-by-design" point and how it's
>> relevant to the IETF. I don't recall discussions about that on
>> IETF/IRTF lists. Is this perhaps something that's really being
>> discussed outside the IETF/IRTF context? If so, then the
>> statement that these are a "new focal point" is not correct.
>> (If you want to say this should or could be a discussion to
>> have, that'd be fine but that's a different statement.)
>>
>> 4: "tools of enforcement" - I'm not sure what you mean here. If
>> you mean law enforcement then saying that would be better, but
>> the sentence is vague, for me anyway so would be better
>> rephrased.
>>
>> 4: "This document sets out some preliminary steps and
>> considerations for engineers to take into account when
>> developing standards and protocols." I think that's a good and
>> fair statement of where this document is at. But don't you
>> elsewhere go further? (CHECK)
>>
>> section 5: It'd be great if you could add links or references
>> to the source materials here. For example, who'd you interview?
>> Are the videos avaiable? What's the list of RFCs you read and
>> which were considered (most) relevant? Similarly for WG lists
>> analysed etc. I'm sure you have all that stuff and making that
>> available for later would be great.
>>
>> 5.2.1.4 and 5.2.1.5: (See general point #4 above about "=") I
>> don't think you actually have achieved this "the creation of a
>> list of technical concepts that when combined create an
>> enabling environment for human rights." It's a fine goal, but
>> I'm not sure it's achievable in reality with the kind of
>> precision claimed in this section.  I don't think the terms
>> used in the figure in 5.2.1.5 are at all precise TBH, e.g.  the
>> phrase "good enough" only occurs in this figure and nowehere
>> else.
>>
>> 5.2.3: "These capabilities for network control and limitations
>> of the freedom of expression by end hosts can be traced back to
>> the IPv4 design..." I don't think you have justified this
>> claim. My argument would be that there is no simlarly
>> scaled/robust nework against which to compare IP and that does
>> not have the feature that it allows deployments to limit
>> freedom of expression. So it may be that this feature/bug is
>> not IP specific but inherent in large networks. In any case,
>> the claim seems too much to me. (That might be a useful topic
>> for the RG to tackle, or maybe someone has already studied this
>> issue?)
>>
>> 5.2.3.1: On what do you base the claim that source-routing
>> could be better here? Source-routing seems to usually generate
>> objections from transport folks. (You'd have to ask them for
>> the history of that.) Spoofed source IP is a common mechaism
>> for abuse.  While you do say these are not considered good
>> practice, you don't say why (or provide a reference) so it
>> looks to this reader as if you're saying that those "features"
>> could have been better, but without evidence for that.  (Tor is
>> lovely, but as currently defined, would not scale to the size
>> of the Internet as it was quite some years ago.)
>>
>> 5.2.3.2: are you referring to the protocol number here? (As
>> listed at [1]) That has about 140 protocols many of which
>> aren't in widespread use.  If so, then I question the claim
>> that this is really the cause of DPI - I suspect that DPI
>> devices mostly look deeper into the packet. That also seems to
>> be indicated when you talk about transports and spdy. I think
>> this section is confused about the differences between headers
>> at various layers, and our history of sending cleartext.  That
>> said, I could see that in future, as we encypt more Internet
>> traffic, someone may find rights-invading ways to use layer 3
>> headers but I'm not sure this is a significant issue today. (If
>> there is evidence of this being done, I'd be interested in
>> knowing about that. I guess there may be IPv6 options that are
>> in use like that or have been suggested but you don't cover
>> those at all that I can see.)
>>
>>    [1]
>> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
>>
>> 5.2.3.3: I don't think mobile IP could never have displaced NAT
>> for IPv4.  We'd still have run out of addresses. So I'm not
>> sure the point made here (that there was a "viable
>> alternative") is correct at all.
>>
>> 5.2.4: "which enact ICANN's policy" Do you thnk that the ccTLDs
>> would agree with that? I don't.
>>
>> 5.2.4: I think the fact that new gTLDs are hugely expensive is
>> well worth a mention, as a deterrent to various freedoms.
>>
>> 5.2.4: I think you're missing some points here, maybe even an
>> entire subsection. One of the ways around some of the issues
>> listed is for clients to choose their resolver, e.g. so as to
>> pick one that does check DNSSEC or that is not subject to the
>> same regime as a default resolver. That can be blocked at the
>> IP level, which is one issue. But even if I do that and use
>> DPRIVE, then that creates a new threat of centralisation of
>> lots of queries (e.g. at 8.8.8.8) which introduces yet another
>> point at which control can be enforced or where traffic can be
>> analysed. Passive DNS also has good and bad aspects. I'd say
>> some or all of these points would be good to note. (But I'm not
>> the right person to suggest good text sorry.)
>>
>> 5.2.5: The lack of a mandate for TLS was not the only reason
>> why the web started out largely cleartext. There were also
>> significant performance, UI, tooling and missing infrastructure
>> issues, as well as the charging per certificate business model.
>> Those were more important issues IMO, even though they do not
>> nicely tie into the discussion of h2 and it's lack of a mandate
>> for use of TLS. While I personally regret that, it was the
>> result of a real and extended and open debate, which I think
>> also ought be noted.
>>
>> 5.2.5 and 5.2.5.x: While I'm fine with you calling the
>> development of TLS MitM devices and similar "malicious," I am
>> pretty sure plenty of folks might argue that. It'd be better to
>> skip the pejorative language I think, but it is entirely
>> correct to have the references to the attacks mounted using
>> such technologies. I'd also tend to not mention specific
>> companies and products in the body of the text, except where
>> that is really necessary to make the point.
>>
>> 5.2.5.1: How do you know it was Snowden's relevations that
>> caused mail service providers (not ISPs!) to "follow Google's
>> lead"? That may be correct, but I'm not sure there's the public
>> evidence that they said that was why. (If there is, great, but
>> please provide a reference, the one you do provide, [Peterson],
>> is about gmail and not yahoo.) Also, Google use TLS, not SSL
>> for gmail.
>>
>> 5.2.5.1: "less democratic" - I think it's an error to say that,
>> since many countries that are considered role models for
>> democracy could do the same things, "some countries" and
>> examples would be better. Same with "oppressive regimes" -
>> there's no need to include that judgement here.  The reference
>> here [RSF] wasn't accessible to me (no route to host) from a
>> hotel network and eduroam. That could be nicely ironic, or a
>> badly chosen reference. (But you need a reference.) The 2012
>> Libya report also really needs a reference.
>>
>>    [RSF]
>> https://en.rsf.org/syria-syria-using-34-blue-coat-servers-23-05-2013,44664.html
>>
>> 5.2.5.2: wrt great-cannon, you might want to note that the IESG
>> issued a related statement [2]. That's a bit tangential, but I
>> think is relevant for this work.
>>
>>    [2]
>> https://www.ietf.org/iesg/statement/maximizing-encrypted-access.html
>>
>> 5.2.5.2: "Companies like" is pejorative and the patent
>> application seems irrelevant. "has been largely documented"
>> calls for a reference. "Oppressive regimes" is also not needed
>> here as is "little concern for bad human rights records." The
>> right thing here I think is to note the documented record
>> without pejoratives and to then let the reader draw their own
>> conclusions.
>>
>> 5.2.5.2: I don't think the text about h2 is fair. You're
>> missing a) that there was a real and open debate on the topic,
>> b) that some important implementations are exclusively h2/tls
>> and c) that there is a spec for OS for HTTP being developed.
>> Those are all as relevant as the fact that the outcome of the
>> debate was to not mandate use of TLS all the time. (Which I do
>> think is worth saying in this document, but needs more complete
>> context.)
>>
>> 5.2.6: I think this section is missing some things. First, the
>> IETF/XSF relationship is relevant here and needs a mention. (As
>> both good and bad!) Second, OTR is important, as is the
>> community's failure to produce a better e2e standard for xmpp.
>> And lastly, I think the tendency of IM deployments to not
>> deploy interoperable standarsd is missing, which also has good
>> and bad aspects (good: they can do telegram etc, bad: no
>> interop).  I'd suggest asking an XMPP expert to review/suggest
>> text.  (Happy to help find you one if needed.)
>>
>> 5.2.6: "The protocol also has facets that may stifle speech as
>> users self-censor for fear of surveillance, or find themselves
>> unable to express themselves freely." That's not an XMPP
>> specific point - the same applies to email and the web and to
>> any other protocol that supports interpersonal messaging or
>> access to sensitive information. I think you ought up-level
>> this point to a more generic section that calls out issues with
>> multiple protocols. (Not sure where exactly, but having it here
>> only isn't great.)
>>
>> 5.2.7: Is this section about P2P in general (I'd consider P2P a
>> design pattern) or about PPSPP or about BT? Each of those
>> choices seems wrong. If the first, then that's not the same as
>> other 5.2.x sections and doesn't mention other P2P protocols
>> (e.g. RELOAD maybe). If the second, is the deployment of that
>> sufficient to justify the text? If the 3rd - that's not an IETF
>> protocol. So I'm not sure what to make of this.
>>
>> 5.2.7: Is it still true to say that P2P is an "increasingly
>> becoming a popular architecture"? I thought usage stats were
>> showing the opposite nowadays? The examples given are odd: as
>> BTC doesn't do file sharing/interpersonal messaging, skype is
>> no longer really P2P iiuc, and I don't know if spotify really
>> is or not. Surely BT is the canonical real example?
>>
>> 5.2.7: "mostly delegated" - I'm not sure this is correct.  I
>> could argue that RELOAD is a counter example. I could further
>> argue that the lack of deployment of RELOAD (iiuc) may be
>> evidence that your implied argument that it'd be better for an
>> organisation like the IETF to try produce complete specs in
>> this space might be unwise in that it's less likely to result
>> in deployment.
>>
>> 5.2.7.3: I think ledbat has some protocol features that would
>> allow deployments (if they are nice) to reduce the scope for
>> tracking. That's RFC 6817 but I'd have to reread it to check if
>> there's something useful there, also not sure about ledbat
>> deployment.
>>
>> 5.2.7.4: Sybil attacks in this context (e.g. astroturfing) seem
>> to be relevant to more than p2p protocols. In fact wouldn't
>> they be more common on web based systems, at least as exploited
>> by/for governments and commercial entities?
>>
>> 5.2.8: There are many kinds of VPN - I think it'd be better to
>> rename this section to something like "personal VPNs" or
>> similar, as you don't get into e.g. corporate VPNs.
>>
>> 5.2.8.1: "local illegitimate wiretapping" - that's another
>> pejorative term for some, "monitoring" would be just as clear.
>> (Again, not because what you say is wrong, but because there's
>> no point in antagonising those who read this.)
>>
>> 5.2.8.1: "are way less analyzed and understood" I think I
>> recall some papers on these kinds of VPN that found some issues
>> - be good to reference such work if possible, esp if there's a
>> survey.
>>
>> 5.2.8.3: " VPN providers should at least be transparent on what
>> information do they store and for how long is being kept" I
>> fully agree with this, but what's it telling the IETF
>> readership? Perhaps that RFCs ought identity potentially
>> sensitive logged data or for how long that needs to be retained
>> for technical reasons? That migth not belong here anyway but
>> could be relevant somewhere in the document.
>>
>> 5.2.9: This could be shorter and may better as a part of
>> section 5.2.5 - why is this one status code so important?
>>
>> 5.2.10: I'm really not sure this (all) belongs here.  The
>> middlebox debate is old and won't be resolved here, so I'm
>> don't think it's worthwhile regurgitating the arguments in such
>> detail. And I think you already said what you need to say when
>> discussing NATs. I'd say deleting this section is maybe right.
>>
>> 5.2.10: (If you keep it) "IETF's role to prevent such
>> censorship" again, the IETF is not the Internet police and does
>> not "prevent" things like that. If you refer to the SPUD BoF,
>> you should include references to the minutes etc.
>>
>> 5.2.10: "Middleboxes are becoming a proxy for the debate on the
>> extent to which commercial interests are a valid reason to
>> undermine the end- to-end principle." That seems like an
>> opinion, and one I'd be surprised had consensus. Do you need to
>> say that?
>>
>> 5.2.11: "Some people may say that DDoS attacks are the only
>> mean to be heard, in the current Internet." Some people say
>> that the moon landings were faked. Vague reportage like that is
>> useless. I'd say this entire section needs to be redone with a
>> strong statement that there is no valid use-case for DDos, and
>> that DDoS is not a valid form of protest. I think such a
>> statement is one that would have RG and indeed IETF consensus.
>> I'm very sure that no concept of DDoS as a valid form of
>> protest would garner consensus in either the RG or the IETF.
>>
>> 5.2.11: "seem to suggest that the IETF should try to ensure
>> that their protocols cannot be used for DDoS attacks" That's
>> very understated and maybe even misleading. I would say that
>> the IETF has long-standing consensus that DDoS is an attack
>> that protocols should mitigate to the extent they can and that
>> DDoS vectors in protocols are basically bugs.  RFC3552 (section
>> 4.6) from 2003 covers this and says that standards MUST
>> describe DoS issues.
>>
>> 5.2.11: The linkage between private sector control of networks
>> and DDoS is IMO entirely unconvincing. NRENs are generally
>> private sector and have major issues with DDoS. (I'm sitting in
>> a talk on that topic right now.) It is not at all clear that
>> anyone who'd claim that they are using a DDoS attack to protest
>> would actually be protesting about a network operator - it is
>> much more likely they are protesting about some content owner,
>> who may be public  or private sector.
>>
>> 5.2.11: I don't think we need or want the argument based on PM
>> here at all. The argument about motivations for PM in RFC7258
>> depends on there being some justifiable reasons for monitoring.
>> (Otherwise we would not need to even point out that motivations
>> don't matter.) There are no such close-to-good arguments at all
>> for DDoS, so drawing that analogy is misleading.
>>
>> 5.2.11: If the RG feel there is a need to discuss a possibility
>> for fully opted-in people to collectively protest, (I do not)
>> then you should invent a new term for that and clearly say that
>> even though such protest might appear to the network as beng
>> the same as a DDoS (and hence be treated as an attack), that is
>> not the same as a DDoS, where 100% of real cases involve
>> compromised hosts or hosts being used as reflectors without
>> permission. If the RG feel there is a need to discuss forms of
>> protest on the Internet, then I think an entirely different
>> section is needed, probably with a different structure.
>>
>> 5.3.1: I'm not sure the "HR threats" model is the right thing
>> here. The same was true of rfc6973 as well, as you say, but in
>> this case, I'm not sure you really even need the concept. 5.3.2
>> just says stuff like "did you think about <foo>" so I don't see
>> a need to say that "<foo> is a threat." I don't think you lose
>> anything by losing that concept entirely. There is also a
>> danger in including that risk analysis model here in that doing
>> so might cause later disussion to be somewhat blinkered.
>>
>> 5.3.1: "This is by no means an attempt to cherry picks rights,
>> if other rights seem relevant, please contact the authors
>> and/or the hrpc mailinglist." I'd delete that, it's not that
>> appropriate for an RFC (it was for an I-D). But if you do want
>> to say something about a contact point, the RG list would be
>> better. (The phrasing "cherry pick" is also a bit odd.)
>>
>> 5.3.2: The title here is a bit inaccurate and misleading.
>> You're presenting guidelines for protocol designers, and not
>> for "HR considerations."
>>
>> 5.3.2: I don't think that many IETFers follow or read RFC4101.
>> (RFC4101 is a useful, good thing, but one that's not much used
>> iiuc.)
>>
>>
>> 5.3.2.1.2: We're updating RFC3552 now, and the update will
>> include some guidance on privacy considerations. I'm not sure
>> if it'd be better to reference that draft now or not though, as
>> it's early days. Probably best to refer to BCP72 though, as
>> that'll remain the right reference when the 3552bis work is
>> done.
>>
>> 5.3.2.1.2: "Could your protocol counter traffic analysis, or
>> data minimization?" oops - I don't think you want to counter
>> data minimisation. Better to split that into two questions
>> probably.
>>
>> 5.3.2.1.3: This set of questions need work. All protocols "look
>> at the packet content" or else do nothing at all. I think you
>> want to ask people to think about which fields in the packet
>> they need to access and to try to minimize those, and if
>> possible, discourage others from looking at the rest (e.g. by
>> enabling encryption of those).  I also have no clue what " Is
>> the protocol transparent about its decisions?" means. And the
>> last question is also pretty meaningless when looked at in
>> isolation. (I think I already commented on the agnosticism
>> phrase as used here before. The same issues apply to the
>> explanatory text here.)
>>
>> 5.3.2.1.5: "readable by humans" is not the right criterion
>> here. What you need to say is that "have to be understood by
>> humans." For example, DNS names are mostly readable but IDNs
>> are not, depending on which form one uses. For some protocols
>> it is entirely fine still to use ascii for human-readable
>> labels, if those are only seen by developers or more capable
>> admins.
>>
>> 5.3.2.1.6: Re-using existing identifiers (e.g. MAC addresses)
>> is the more common way that (re-)identification is enabled in
>> protocols. You should point that out. I think the "make ...
>> transparent" point is worth splitting from the identifier issue
>> too - identifiers are very common, but making filtering
>> apparent is much less so, and will be missed if you bundle
>> these two things together. The last two questions aren't really
>> useful though and are more explanatory text then real new
>> questions.
>>
>> 5.3.2.1.7: These are not useful, as phrased for IETFers.  The
>> only useful part here is the 2nd last question (use other
>> things that are proprietary), the rest are not as they are
>> already handled in IETF processes, and we do not want yet more
>> bureaucracy. The explanatory material is way too long and also
>> not useful for the IETF audience. The example given is an
>> interesting thing, but far from a typical protocol, so
>> therefore is not a good example.
>>
>> 5.3.2.1.8: This entire section is useless for IETFers, except
>> the last question about extensibility. The explanatory text and
>> example however don't address that and are also not useful.
>>
>> 5.3.2.1.9: The question was asked already. Anonymity is not a
>> useful goal in almost all IETF protocols, and if it were, it'd
>> be a first order requirement (e.g. if we wrote an RFC for Tor)
>> and would not be missed. Delete this section entirely.
>>
>> 5.3.2.1.10: The emphasis here is wrong. You should be asking
>> about whether the protocol generates or processes anything that
>> can be, or be tightly correlated with, PII. Many protocols have
>> identifiers that are perfectly safe, until the host running the
>> protocol is something that a person carries with them. The
>> section needs a rewrite to take that approach.
>>
>> 5.3.2.1.11: Mixing accessibility and statefulness is wrong.
>> Both are fine questions, but should not be bundled.  The
>> example is bad - HTML5 is the current spec and is not that RFC.
>>
>> 5.3.2.1.12: I think this is arguably duplicative and the issue
>> will (or should) be caught via other IETF processes apart from
>> HR considerations. I'd delete this, though it's mostly harmless
>> here.
>>
>> 5.3.2.1.13: Again, this bundles things in a counterproductive
>> manner. Split the topology/architecture points from the
>> discriminaton/implication ones. (Even if you think those relate
>> in terms of HR, that does not mean that they ought be bundled
>> together in a questionnaire.)
>>
>> 5.3.2.1.14: I don't think this belongs in the questionnaire
>> either. It's covered alredy in other IETF processes, when most
>> relevant, so is not useful to ask about here.
>>
>> 5.3.2.1.15: This needs to be rewritten, there are 13 questions
>> in the text which is entirely pointless. I would not bother to
>> try answer those. You should just ask how confidentiality is
>> supported and between what endpoints and how keying is done.
>> (Or something like that, I didn't try the full re-write that is
>> needed.) The re-write should also bundle this with most of the
>> next two sections. (See below.)
>>
>> 5.3.2.1.15: The cryptographic parts of this should be merged
>> into a rewritten 5.3.2.1.14. If there are non-crypto bits of
>> this then those need better explanatory text as it'd not be
>> relevant for most protocols. (I mean things like database
>> consistency.) I'm not sure if anything would remain when this
>> and the previous section were re-written.)
>>
>> 5.3.2.1.17: As per 5.3.2.1.16.
>>
>> 5.3.2.1.18: This is entirely duplicative and should be deleted.
>>
>> 5.3.2.1.19: I've no clue if this'd be useful to ask. Only
>> testing would tell. (It might be, but I'm really not sure.)
>>
>> Nits/editorial...
>>
>> lots of places: there are too many over-long sentences that
>> make this hard to read and less clear. I'd really recommend
>> getting rid of as many of those as you can. The first non-quote
>> paragraph of the intro is a good example.
>>
>> intro, "the core of the Internet, its architectural design
>> is..." Using "core" is a bad term there, mostly we mean
>> something quite different when we talk about the Internet's
>> core or similar.  (And that's another assumption that there's
>> one true architecture.)
>>
>> intro, "properly defined, described and protected as such" - I
>> don't think "defined" is needed there, and it might not be
>> correct either.
>>
>> intro, "New protocols, particularly those that upgrade the core
>> infrastructure of the Net, should be designed to continue to
>> enable fundamental human rights." I'd drop the "core
>> infrastructure" bit there, it's a distraction and liable to
>> generate argument about what is or is not core, e.g. BGP is
>> clearly core but is not otherwise mentioned in this document,
>> and maybe correctly.
>>
>> intro, "The authors believe that the issues that have been
>> raised by the reviewers have been addressed." Sorry to be
>> raising more:-)
>>
>> section 2: I think some better formatting is needed here to
>> distinguish the terms defined from the text, which in some
>> cases is fairly long. Just add bullets or quoting or something.
>>
>> 2: "In the discussion of human rights and Internet architecture
>> concepts developed in computer science, networking, law,
>> policy-making and advocacy are coming together" Sorry, what is
>> coming together in what discussion(s)? Too many commas there to
>> be sure I think. (BTW, "architecture concepts" may well be an
>> ok use of that word:-)
>>
>> 2, "censorship resistance" does not "prevent" censorship, I'd
>> say mitigate is better than prevent.
>>
>> 2, "confidentiality" - why not refer to 4949 there?
>>
>> 2, "debugging" - the term debug is not used in the draft, why
>> do you need the definition?
>>
>> 2, "decentralized" - why is "opportunity for" needed in this
>> definition? I don't get that.
>>
>> 2, "technical this means..." needs fixing.
>>
>> 2, "Heterogenity" typo
>>
>> 2, "autonomous organizations" do you mean ASes? If so, say so.
>> If not, better to avoid the word autonomous here.
>>
>> 2, "integrity" - why not refer to 4949?
>>
>> 2, "Inter-operable" is normally not hyphenated in the IETF
>>
>> 2, i18n - funny line breaks there make that hard to read
>>
>> 2, l10n - you don't actually use that abbreviation so why
>> define it?
>>
>> 2, "The combination of the end-to-end principle,
>> interoperability, resilience, reliability and robustness are
>> the enableing factors that result in on the Internet.  " That
>> (non-)sentence needs fixing. I don't even know what you want to
>> say tbh.
>>
>> section 3: I think this short section is missing text to the
>> effect that you think the answer to question 2 is yes.
>>
>> section 4: you say "five clear positions" but they are not
>> clearly delineated in the document. I'd suggest using some
>> headings or some other way to make these more distinct in the
>> document.
>>
>> 4: "embedded into the Internet's architecture" (top of p13) has
>> another claim that there's one true Internet architecture.  You
>> could change this one to be the set of protocols defined by the
>> IETF or something similar.
>>
>> 4: " As it stems from the issues as they arise in the field of
>> technical engineering." That's not a sentence.
>>
>> 5: "step taken by the research group" that's ambiguous - I
>> think you mean the set of authors and their research groups at
>> home and not the HRPC, which I don't think collectively read
>> all the RFCs you mean. (I think it's fine to say that the
>> authors were the one who did the work, if that's what you
>> mean.)
>>
>> 5.1: This section duplicates the intro to section 5. Is there a
>> new point being made?
>>
>> 5.2: "(detailed under "2.vocabulary used")" do you mean section
>> 2 there? Saying "Section 2" with the right xml2rfc incantation
>> will cause the tools rendering to make that a link, which'd be
>> nice.
>>
>> 5.2.1.1: "was assembly" typo.
>>
>> 5.2.1.5: figures are better numbered and with captions.
>>
>> 5.2.2.1: I guess there's a heading level bug here in the
>> document sounce?
>>
>> 5.2.3.1: "ability for those hosts to assemble or to
>> consensually express themselves" huh? When/how do hosts
>> assemble or do things consensually? Confusing people and hosts
>> like that is odd.
>>
>> 5.2.3.2: Why refer to spdy and not h2? And is that even a good
>> reference? The 4906 reference also puzzled me. (Even more:-)
>>
>> 5.2.5: Why "because of it's simple design"? I'd have thought it
>> was more complicated than that and that a combination of HTTP,
>> HTML, open-source browsers and web servers and cool content was
>> involved.
>>
>> 5.2.5: TLS and SSL could do with references.
>>
>> 5.2.5: Gen-ART? Huh? That's wrong. Gen-ART are fine people but
>> they don't do what you say they do any more than any other set
>> of IETFers. Are you confusing them with the IAB statement on
>> encryption perhaps? Otherwise that is quite the puzzle for
>> me:-)
>>
>> 5.2.5.1: What does "of the first" mean? "From the start"?
>>
>> 5.2.5.1: "have been corrected in TLS1.3" is in the wrong tense
>> - "are being corrected" is correct.
>>
>> 5.2.5.1: TEMPORA, XKEYSCORE etc need references. Those can get
>> hard to find later, at least good references can be hard to
>> find.
>>
>> 5.2.6.1: I assume the URLs [1] and [2] don't need to be there
>> and are xml2rfc artefacts to be fixed. Also, you should use
>> example.com and example.net as per the usual way of handling
>> examples in RFCs.
>>
>> 5.2.7: "often seen" - by whom? I'm not sure that IETFers would
>> share that opinion, so better to say who you do mean. "remains
>> critical" is also overstated.
>>
>> 5.2.7.1: "directed directly" typo
>>
>> 5.2.7.2: "throtteling" typo
>>
>> 5.2.7.5: Why does only this section have a conclusions
>> subsction? I'd say be consistent.
>>
>> 5.2.8.1: you could lose the heading here (consistency again:-)
>>
>> 5.2.8.1: some VPNs (but not the ones you care about) are not
>> point-to-point.
>>
>> 5.2.8.1: "There are multiple implementations and protocols used
>> in provisioning a VPN" do you really mean provisioning a VPN
>> there? That'd mean something else for some IETFers. I think you
>> mean setting up a personal VPN for a single user but not quite
>> sure.
>>
>> 5.2.8.5: The URL for [PET2015VPN] didn't work for me. I found
>> the paper elsewhere though.
>>
>> 5.2.8.7: This bit seems fairly repetitive, other than the
>> timing/correlation issues. You could maybe say that more
>> briefly.
>>
>> 5.2.10: The URL for [Walfish] doesn't point at the named paper
>> - what's up there?
>>
>> 5.2.11 (and elsewhere): "Many individuals, not excluding IETF
>> engineers, have argued..." I hate constructs like that that
>> assert that somebody somewhere (unnamed) thinks/says something.
>> I don't see why any such assertions (of rumour basically) ought
>> be in the RFC series. There are other examples of this
>> construct in the draft.
>>
>> 5.2.11: Not all DoS attacks flood with traffic. Some might
>> consume CPU cycles, in future some will consume limited power,
>> and could be used in a DDoS. I don't think it's useful here
>> (for the IETF audience) to define 3 types of DDoS attack.
>>
>> 5.3: "Having established how..." I don't think you established
>> the "how." It'd be fair to do s/how/that/ though. (Twice.) That
>> sentence is also overlong. Also "... by detailing how..." is
>> similarly not correct.
>>
>> 5.3.1: 1st para is repetitive. Delete it.
>>
>> 5.3.1: The term "ICTs" isn't common in the IETF community. I'd
>> say rephrase stuff to not use that.
>>
>> 5.3.2.x.y: Having such deep levels of TOC makes life harder for
>> readers and those commenting and later using this. Flatten it
>> tall out. Or, do you even need the 5.3.2.x.y headings at all?
>> (Some of the section titles don't map that well to the
>> content.)
>>
>> 5.3.2.1.1: s/e2e principle/e2e argument/ again:-)
>>
>> 5.3.2.1.1: the communication content would be concealed, not
>> the act of communication
>>
>> 5.3.2.x.y: It'd be a very good idea to add an appendix that
>> lists the questionnaire questions only (with those being
>> numbered). That way, people who want to do this analysis can
>> just use that part (at least the 2nd time).  If doing that,
>> please ensure each question also has an unique number/label in
>> the body of the document too, so that folks can find/correlate
>> things.
>>
>> 5.3.2.1.4: The last para of explanatory material should not
>> re-define COMSEC etc. Just point people at RFC3552/BCP72.  (But
>> as BCP72.) The global adversary is also not purely passive, I'd
>> lose that phrase.
>>
>> 5.3.2.1.5: "many protocols" is not usefully true I think.
>>
>> 10.2: delete this.
>>
>>
>>
>>
>> _______________________________________________
>> hrpc mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/hrpc
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> 
> _______________________________________________
> hrpc mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hrpc
>