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

[Stephen Farrell <[e-mail]>]

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.