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

[Gurshabad Grover <[e-mail]>]

Eliot, thanks very much for your review! Replies in-line.

On 5/20/21 5:38 PM, Eliot Lear wrote:
> 
> 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.
> 

I think the explanation and examples under each each sub-section of 2.3
are intended to make these links explicit. Are you referring to some
other sort of links between rights and properties of protocols/specs?

> *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,

Good point. Made it into a new section in the recent update.

> 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.
> 

As I understand it, we are not proposing an ideal workflow as such. We
are just listing out some assessment frameworks (which may be used
independently or in conjunction with each other).

> 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".
> 

I don't think we're saying this explicitly anywhere, but that's
deliberate. Since IETF is not the only place where protocols are made, I
think that this vagueness is acceptable. Of course, one of the primary
goals for the document remains that it is usable by people at IETF.

That said, I think we were at consensus that the guidelines are not just
relevant to protocols, but specifications (an example at IETF would be
specifications that lay out an architecture but not a protocol) in the
broad area of networking. For instance, I think the group has used the
guidelines to review the MLS architecture and SUIT architecture. Made
some changes to say 'specification' instead of protocol where relevant.

> 
> 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.
> 

I don't think I have a strong opinion about this. Before making any
changes in this section, however, I'd love to hear what others think.

> 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.
> 

I agree that identity authentication can be at odds with
anonymity/pseudonymity, but this section is not about that. I re-read
the text and example in this section, and to me it's clear that it's
more to do with transport/data authenticity than identity
authentication. Would love to hear your thoughts on how we can make this
even clearer if it's cause for confusion.

> *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.

Removed the second sentence.

Could you please elaborate on what you mean to demonstrate through the
example here (with respect to linkages of rights)?

> 
> 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.
> 

Clarified the definition; it now says exactly what meaning we're using now.

Thanks again for your review, Eliot. Much appreciated.

-Gurshabad