Re: [hrpc] Working group last call for draft-irtf-hrpc-guidelines

[Eliot Lear <[e-mail]>]

Hi Mallory,

I'm conducting another last call review of this document.  This may be 
one of several mails.

*Major issue:*

For "Impacts"-

These impacts are claimed, both here and in 8280, but the linkage isn't 
explicitly made in each case.  Are these linkages made clear somewhere 
else?  I may have entirely missed it, in which case this issue isn't an 
issue at all.  Otherwise, one wonders if we are putting the cart before 
the horse.

*Somewhere between Minor and Major*

Section 2 & 2.2

I think there is a slight organizational issue, from a readability 
perspective.

It feels to me like 2.1 is really still introductory, and then 2.2 gets 
into what to do, starting with interviews.  It may make sense to move 
2.1 up into Section 1, and then create a new chapeau in Section 2 that 
shows your preferred work flow.

For example:

[concept formation] -> [WG discussion] -> [HR expert consultation] -> 
[impacted community consultation]

-> [modifications] -> ... -> [implementations] -> [tracing impacts] -> 
[revisions]

And there can be while/if loops etc.  A little UML might go a long way here.

Section 2.3 should be consulted throughout, under such a model. You 
could even move that into a new H1 section 3.

A few of the examples seem to me a bit disjoint from the IETF.  I think 
we talked about Accessibility at some point, but an example more 
relevant to the IETF might help people grasp the more direct relevance 
to the organization.  I don't have a particularly good example of this, 
but there should at least be an existence proof of the relevance to 
us... unless...

... you want the guidance to be broader than just the IETF.  I see 
absolutely nothing wrong with that, but you should scrub the doc then to 
make sure that IETF-specific stuff is generalized.  An example might be 
to replace "protocol" with "specification".

Along these lines, I am still ruminating over Section 2.3.10, which may 
need a separate email. It's clear that there are things that can be done 
at the IETF, and things that can be done elsewhere.

Section 2.3.13

I don't know that we have *any* real success stories for 
decentralization.  HTTP certainly isn't one.  Certainly designing 
*toward* centralization might be best, but I don't think we have very 
many examples of that *either.*  Moreover, I have argued, and continue 
to argue, that some centralization may *facilitate* human rights.  If 
you take into account the combination of DOH + cloud, an observer must 
go to far greater lengths to discern even so much as the nature of the 
traffic, much less content and actual endpoint.

And this raises another issue: the point of much of cloud services is to 
improve individual service reliability.  And yet those same cloud 
services are a form of centralization.  If you consider that perhaps a 
handful of players might force DNS traffic to a limited number of 
resolver services, we might also say that DoH itself presents 
centralization risks.

These sorts of conflicts are of course to be expected.  The question is 
whether it is worth providing guidance relating to centralization.  I 
will claim that nobody yet has a real handle in this area, and so better 
to say nothing in the form of guidance. Instead, it seems to me to be 
good fodder for future work.

2.3.17 Authenticity

The authors write:

>     At the same time, authentication should not be used as a way to
>     prevent heterogeneity support, as is often done for vendor lock-in or
>     digital rights management.

As if that should be the #1 concern.  Perhaps a bigger concern is that 
authenticity directly conflicts with anonymity or pseudo-anonymity.  If 
someone is forcing you to authenticate, the authentication identity can 
and will be associated with whatever access takes place, and that 
information can be demanded.

Furthermore,  I'm not at all sure that the example holds up, and it 
should be at least supported by a current reference.  Finally, there are 
conflicts here as well: the technology that one might use for vendor 
lock-in is  the same as that used to validate the authenticity of 
software, for purposes of preventing malware spread.

Also, the question itself is a bit shallow.  Authenticity of what?  If 
we are talking about the underlying data, a mere transport connection 
may not in and of itself provide sufficient protection.  We have plenty 
of mail traversing encrypted tunnels and lots of spam to go with.

*Minor issues:*

Beginning with Section 1:

>    This is by no means an attempt to exclude specific rights or
>     prioritize some rights over others.  If other rights seem relevant,
>     please contact the authors.

Are we are sufficiently taking into account how linkages to other rights 
might prevail?  Let me give an example:

If we are talking about a new version of "whois" that retrieves 
information necessary for law enforcement, the whole point of the 
protocol is to expose information that some would say is private. And so 
the question revolves around whether appropriate protections are in 
place to limit access to that information to authorized parties.  
However, even doing that may not be enough, if "authorized parties" are 
the source of abuse.  I don't know if such an example is an outlier, but 
there it is.

Nit: the 2nd sentence will need to be changed or removed.

2.3.12 "Localization"

Be advised that this term has distinctly different meanings.  In trade 
parlance it is a barrier to trade through local requirements.[1]  A TBT 
can also be viewed as a means to restrict content that isn't translated 
(ie, stuff that censors can read). I think this might be worth a 
mention, just because they're related and yet potentially conflicting.

Ok, I'll stop there for now.

Eliot

[1] https://ustr.gov/trade-topics/localization-barriers