Subject: [regext] "Considerations" Sections

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 6 Nov 2018 08:01:40 +0000

Following up on the in-room discussion regarding Human Rights Protocol Considerations as compared to Security Considerations and other types of considerations that appear in IETF documents:

I mentioned at the mic that we don't have any documents representing IETF consensus that provide guidance for writing human rights protocol considerations. It was mentioned that RFC 8280 describes such guidelines. True, it does, but it's an Informational document that "represents the consensus of the Human Rights Protocol Considerations Research Group of the Internet Research Task Force". RFCs 3552 (Security Considerations) and 8126 (IANA Considerations) are, in comparison, IETF BCPs. So, I'll stand by my comment regarding the lack of _IETF_ consensus on the topic.

Scott

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 6 Nov 2018 09:06:57 +0100

> I mentioned at the mic that we don't have any documents representing IETF consensus that provide guidance for writing human rights protocol considerations. It was mentioned that RFC 8280 describes…

Thanks Scott, as you know there are also Privacy Considerations, as outlined in RFC6973, which also do not constitute community consensus but are widely used. 

Furthermore, if something is not a community consensus, it doesn't mean we MAY/SHOULD/MUST NOT do it. 

Best,

Niels

> 
> Scott
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 6 Nov 2018 08:22:12 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Niels ten Oever
> Sent: Tuesday, November 06, 2018 3:07 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [regext] "Considerations" Sections
>
> > Following up on the in-room discussion regarding Human Rights Protocol
> Considerations as compared to Security Considerations and other types of
> considerations that appear in IETF documents:
> >
> > I mentioned at the mic that we don't have any documents representing
> IETF consensus that provide guidance for writing human rights protocol
> considerations. It was mentioned that RFC 8280 describes such guidelines.
> True, it does, but it's an Informational document that "represents the
> consensus of the Human Rights Protocol Considerations Research Group of
> the Internet Research Task Force". RFCs 3552 (Security Considerations) and
> 8126 (IANA Considerations) are, in comparison, IETF BCPs. So, I'll stand
> by my comment regarding the lack of _IETF_ consensus on the topic.
>
> Thanks Scott, as you know there are also Privacy Considerations, as
> outlined in RFC6973, which also do not constitute community consensus but
> are widely used.
>

True. It also does not mean that we MUST do it. As Jim Galvin noted, it's up to the editor and WG to decide how to address the topic.

Scott

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 6 Nov 2018 09:35:30 +0100

> True. It also does not mean that we MUST do it. As Jim Galvin noted, it's up to the editor and WG to decide how to address the topic.

My understanding is that at the point of WG adoption, change control is handed over to the WG, right? So in that case it means that it is up to the WG.

Best,

Niels

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 6 Nov 2018 08:59:17 +0000

> From: Niels ten Oever <[email-masked]>
> Sent: Tuesday, November 06, 2018 3:36 AM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]'
> <[email-masked]>
> >> Considerations as compared to Security Considerations and other types
> >> of considerations that appear in IETF documents:
> >>>
> >> IETF consensus that provide guidance for writing human rights
> >> protocol considerations. It was mentioned that RFC 8280 describes such
> guidelines.
> >> True, it does, but it's an Informational document that "represents
> >> the consensus of the Human Rights Protocol Considerations Research
> >> Group of the Internet Research Task Force". RFCs 3552 (Security
> >> Considerations) and
> >> 8126 (IANA Considerations) are, in comparison, IETF BCPs. So, I'll
> >> stand by my comment regarding the lack of _IETF_ consensus on the
> topic.
> >>
> >> outlined in RFC6973, which also do not constitute community consensus
> >> but are widely used.
> >>
> > True. It also does not mean that we MUST do it. As Jim Galvin noted,
> it's up to the editor and WG to decide how to address the topic.
> >
>
> My understanding is that at the point of WG adoption, change control is
> handed over to the WG, right? So in that case it means that it is up to
> the WG.

The editor controls the pen. It's the responsibility of the editor to ensure that the text that appears in the document ultimately represents WG consensus.

Scott

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 6 Nov 2018 10:32:21 +0100

> The editor controls the pen. It's the responsibility of the editor to ensure that the text that appears in the document ultimately represents WG consensus.

I thought that it is up to the WG chair to establish what does or does not constitute consensus. 

Am also a bit confused about the interchangeable use of editor and author here. James is the author, right? 

Cheers,

Niels

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 6 Nov 2018 12:00:34 +0000

> On Nov 6, 2018, at 4:32 PM, Niels ten Oever <[email-masked]> wrote:
> 
> 
> 

See Section 6.3 of RFC 2418.

> Am also a bit confused about the interchangeable use of editor and author here. James is the author, right?

He is the author of the pre-WG version. He is the editor of the WG version that is the subject of WG discussion.

Scott

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 6 Nov 2018 16:52:23 +0100

> He is the author of the pre-WG version. He is the editor of the WG version that is the subject of WG discussion.

Are you saying that all people who are listed on RFCs that previously have been adopted by WGs are actually editors, and not RFC authors? I think this is not standing practice across the IETF. 

For instance in the QUIC WG, there are some documents where it is clearly indicated that there is an editor, and and in other cases someone is an author. Compare for instance:

https://tools.ietf.org/html/draft-ietf-quic-http-16
https://tools.ietf.org/html/draft-ietf-quic-manageability-03

Or has there been an agreement in this WG that James is an editor and not an author? Then I think that it should be made clear on the Internet Draft as well. 

Best,

Niels

---

From: Kal Feher <[email-masked]>
Date: Tue, 6 Nov 2018 23:30:56 +0700

>>>>>> True. It also does not mean that we MUST do it. As Jim Galvin noted,
KF I wonder if this is a useful observation. I havent heard anyone
suggest that a HRPC section is required, only that it seems very
appropriate for this draft. So it might be appropriate to focus on why
the section should be or should not be present in the context of how an
implementer might consume the document.
> Or has there been an agreement in this WG that James is an editor and not an author? Then I think that it should be made clear on the Internet Draft as well. 

KF I have no opinion on the author vs editor debate, but I do wonder if
there is any utility to continue the discussion on that point.

There are those who object to including the HRPC section on the basis
that the technology is agnostic and shouldnt be saddled with moral
judgement.

There are those who think the section is a good idea based on the impact
to those whose data is being shared.

I'd much prefer a debate on the relevant topics than document pedantry,
which probably has its place on another list.

-- 
Kal Feher
Melbourne, Australia

---

From: "Gould, James" <[email-masked]>
Date: Tue, 6 Nov 2018 16:50:15 +0000

I don’t believe adding an HRPC section to draft-ietf-regext-verificationcode will assist the implementer in consuming the draft, but instead will add confusion.  What makes it appropriate for this draft over other drafts?  My recommendation is to focus on addressing any applicable technical elements raised, and as Scott recommended, raise the inclusion of an HRPC section in any draft up to the IETF.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 11/6/18, 11:31 PM, "regext on behalf of Kal Feher" <[email-masked] on behalf of [email-masked]> wrote:

    >>>>>>>> Following up on the in-room discussion regarding Human Rights

    >>>>>>>> Protocol

    >>>>>>> Furthermore, if something is not a community consensus, it doesn't

    >>>>>>> mean we MAY/SHOULD/MUST NOT do it.

    judgement.

    --

    Kal Feher

    Melbourne, Australia

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 6 Nov 2018 18:02:22 +0100

On 11/6/18 5:50 PM, Gould, James wrote:
> I don’t believe adding an HRPC section to draft-ietf-regext-verificationcode will assist the implementer in consuming the draft, but instead will add confusion.  

Why would a well formulated paragraph, as laid out in RFC6973 and expanded in RFC8280, add confusing?

> What makes it appropriate for this draft over other drafts? 

I think it would also be appropriate for other drafts, as we've for instance seen today in the discussion of the reverse search.

>  My recommendation is to focus on addressing any applicable technical elements raised, and as Scott recommended, raise the inclusion of an HRPC section in any draft up to the IETF. 

That was not the way forward was summarized by Jim. 

The WG can decide what we add to the draft or not, so I think we should discuss it in the WG and seek for consensus. 

Next to that we can also discuss in other parts of the IETF whether this should be applicable to drafts in general, or how to further and structurally integrate such reviews in our processes. 

Best,

Niels

>     > On 11/6/18 1:00 PM, Hollenbeck, Scott wrote:
> 
>     >>> On Nov 6, 2018, at 4:32 PM, Niels ten Oever <[email-masked]> wrote:
> 
>     >>>
> 
>     >>>
> 
>     >>>
> 
>     >>> On 11/6/18 9:59 AM, Hollenbeck, Scott wrote:
> 
>     >>>>> -----Original Message-----
> 
>     >>>>> From: Niels ten Oever <[email-masked]>
> 
>     >>>>> Sent: Tuesday, November 06, 2018 3:36 AM
> 
>     >>>>> To: Hollenbeck, Scott <[email-masked]>; [email-masked]'
> 
>     >>>>> <[email-masked]>
> 
>     >>>>> Subject: [EXTERNAL] Re: [regext] "Considerations" Sections
> 
>     >>>>>
> 
>     >>>>>
> 
>     >>>>>
> 
>     >>>>> On 11/6/18 9:22 AM, Hollenbeck, Scott wrote:
> 
>     >>>>>>> -----Original Message-----
> 
>     >>>>>>> From: regext <[email-masked]> On Behalf Of Niels ten Oever
> 
>     >>>>>>> Sent: Tuesday, November 06, 2018 3:07 AM
> 
>     >>>>>>> To: [email-masked]
> 
>     >>>>>>> Subject: [EXTERNAL] Re: [regext] "Considerations" Sections
> 
>     >>>>>>>
> 
>     >>>>>>>> On 11/06/2018 09:01 AM, Hollenbeck, Scott wrote:
> 
>     >>>>>>>> Following up on the in-room discussion regarding Human Rights
> 
>     >>>>>>>> Protocol
> 
>     >>>>>>> Considerations as compared to Security Considerations and other types
> 
>     >>>>>>> of considerations that appear in IETF documents:
> 
>     >>>>>>>> I mentioned at the mic that we don't have any documents representing
> 
>     >>>>>>> IETF consensus that provide guidance for writing human rights
> 
>     >>>>>>> protocol considerations. It was mentioned that RFC 8280 describes such
> 
>     >>>>> guidelines.
> 
>     >>>>>>> True, it does, but it's an Informational document that "represents
> 
>     >>>>>>> the consensus of the Human Rights Protocol Considerations Research
> 
>     >>>>>>> Group of the Internet Research Task Force". RFCs 3552 (Security
> 
>     >>>>>>> Considerations) and
> 
>     >>>>>>> 8126 (IANA Considerations) are, in comparison, IETF BCPs. So, I'll
> 
>     >>>>>>> stand by my comment regarding the lack of _IETF_ consensus on the
> 
>     >>>>> topic.
> 
>     >>>>>>> Thanks Scott, as you know there are also Privacy Considerations, as
> 
>     >>>>>>> outlined in RFC6973, which also do not constitute community consensus
> 
>     >>>>>>> but are widely used.
> 
>     >>>>>>>
> 
>     >>>>>>> Furthermore, if something is not a community consensus, it doesn't
> 
>     >>>>>>> mean we MAY/SHOULD/MUST NOT do it.
> 
>     >>>>>> True. It also does not mean that we MUST do it. As Jim Galvin noted,
> 
>     >>>>> it's up to the editor and WG to decide how to address the topic.
> 
>     >>>>> My understanding is that at the point of WG adoption, change control is
> 
>     >>>>> handed over to the WG, right? So in that case it means that it is up to
> 
>     >>>>> the WG.
> 
>     >>>> The editor controls the pen. It's the responsibility of the editor to ensure that the text that appears in the document ultimately represents WG consensus.
> 
>     >>>>
> 
>     >>> I thought that it is up to the WG chair to establish what does or does not constitute consensus.
> 
>     >> See Section 6.3 of RFC 2418.
> 
>     >>
> 
>     >>> Am also a bit confused about the interchangeable use of editor and author here. James is the author, right?
> 
>     >> He is the author of the pre-WG version. He is the editor of the WG version that is the subject of WG discussion.
> 
>     >>
> 
>     > Are you saying that all people who are listed on RFCs that previously have been adopted by WGs are actually editors, and not RFC authors? I think this is not standing practice across the IETF.
> 
>     >
> 
>     > For instance in the QUIC WG, there are some documents where it is clearly indicated that there is an editor, and and in other cases someone is an author. Compare for instance:
> 
>     >
> 
>     > https://tools.ietf.org/html/draft-ietf-quic-http-16
> 
>     > https://tools.ietf.org/html/draft-ietf-quic-manageability-03
> 
>     >
> 
>     > Or has there been an agreement in this WG that James is an editor and not an author? Then I think that it should be made clear on the Internet Draft as well.
> 
>     
> 
>     > Best,
>     >
>     > Niels
>     >

---

From: "Gould, James" <[email-masked]>
Date: Tue, 6 Nov 2018 17:19:21 +0000

Niels,

I belief inclusion of an HRPC section pulls policy into the draft that will add confusion.  We should attempt to pull policy out of the drafts and not go in the other direction.  Do you have an example of another draft or RFC that has included such a section for reference?  
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 11/7/18, 12:02 AM, "regext on behalf of Niels ten Oever" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    Best,
    
    Niels

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 6 Nov 2018 18:32:44 +0100

On 11/6/18 6:19 PM, Gould, James wrote:
> Niels,
> 
> I belief inclusion of an HRPC section pulls policy into the draft that will add confusion. 

Describing the implication of technologies on humans is not at all the same as policy. This is also the standpoint of the IAB, as laid out in RFC6973. So I am not pulling this out of my hat. 

The chair described the way forward on this draft today as follows (as far as I understood it): we would first see what technical amendments to the draft we could make, then see what human rights considerations are relevant, and then seek WG consensus around that. 

Again, I and others are happy to work with you on text that is very clear, and leaves no space for confusion. We can then use that to build consensus in this WG. 

I hope we can continue going down the road suggested by the chair.

Best,

Niels

---

From: Andrew Newton <[email-masked]>
Date: Tue, 6 Nov 2018 13:19:59 -0500

Hello all,

I have a couple of points I wish to make on this thread.

1. With regards to author vs editor, in the most cases they are the
same person. The editor distinction is often made to assuage political
issues or to overcome obstacles related to document production, such
as the original author being unable to complete the work. Regardless,
I don't see how that impacts the current discussion, which is about
the HRPC.

2. In my opinion, I do not believe a human rights considerations
section would negatively impact the readability of this draft if
written properly. That said, the text put forward in the other thread
is certainly not acceptable as it has the tone of "only people who
crush cute puppies under their boots would do this". The text should
be neutral in its advice and merely note the issues, as we see with
most security considerations in the IETF. The text I read said a lot
of things "will" happen instead of "may" happen.

3. I do take issue with some of the text put forward for the human
rights considerations:

a) The section regarding law enforcement subverting a VSP is difficult
to understand in that law enforcement by definition has a monopoly on
power, and therefore they could also simply subvert the will of the
registry or registrar as well. The only point to really be made is
that a VSP in one jurisdiction may impact the operations of a
registrar/registry in another jurisdiction.

b) There is zero mention of the benefits that may come of this with
regard to keeping criminals from using the domain infrastructure. For
example, freedom from harassment seems like it would be a human right
(and yes, I understand there is a fine line between harassment and
free speech, but that's why courts decide such things and not IETF
documents).  I personally do not place much value in this benefit, but
there are certainly others who feel strongly about it.

-andy
On Tue, Nov 6, 2018 at 12:32 PM Niels ten Oever

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 7 Nov 2018 01:18:23 +0000

> Sent: Tuesday, November 06, 2018 10:52 AM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]
> >>>>>> Considerations as compared to Security Considerations and other
> >>>>>> types of considerations that appear in IETF documents:
> >>>>>>>
> >>>>>> True, it does, but it's an Informational document that
> >>>>>> "represents the consensus of the Human Rights Protocol
> >>>>>> Considerations Research Group of the Internet Research Task
> >>>>>> Force". RFCs 3552 (Security
> >>>>>> Considerations) and
> >>>>>> 8126 (IANA Considerations) are, in comparison, IETF BCPs. So,
> >>>>>> I'll stand by my comment regarding the lack of _IETF_ consensus
> >>>>>> on the
> >>>> topic.
> >>>>>>
> >>>>>> Thanks Scott, as you know there are also Privacy Considerations,
> >>>>>> as outlined in RFC6973, which also do not constitute community
> >>>>>> consensus but are widely used.
> >>>>>>
> >>>>>> Furthermore, if something is not a community consensus, it
> >>>>>> doesn't mean we MAY/SHOULD/MUST NOT do it.
> >>>>>
> >>>> My understanding is that at the point of WG adoption, change
> >>>> control is handed over to the WG, right? So in that case it means
> >>>> that it is up to the WG.
> >>>
> >>> The editor controls the pen. It's the responsibility of the editor to
> ensure that the text that appears in the document ultimately represents WG
> consensus.
> >>>
> >>
> > He is the author of the pre-WG version. He is the editor of the WG
> version that is the subject of WG discussion.
> >
>
> Are you saying that all people who are listed on RFCs that previously have
> been adopted by WGs are actually editors, and not RFC authors? I think
> this is not standing practice across the IETF.

Read that section of RFC 2418. Our chairs can answer any other questions you have about roles in this WG.

Scott

---

From: Kal Feher <[email-masked]>
Date: Wed, 7 Nov 2018 09:13:22 +0700

> of things "will" happen instead of "may" happen.

KF I agree with this position. The measure of acceptability for an HRPC
section would have to be that it provides clear comment on the
deployment of the technology, but does not alter ones understanding of
the technology.

I also think that fear of setting a precedent or of being first, should
not govern what is considered useful and appropriate for any draft,
whether that's an HRPC section or not. Either the section is useful and
appropriate or it isnt. Being first should not be relevant to that
assessment.

It might be more productive if the list discussed whether an HRPC is
needed in light of the changing direction of the draft. It could save us
all a lot of time.

> registrar/registry in another jurisdiction.
agree.
> there are certainly others who feel strongly about it.
My preference is to constrain any HRPC section to only those whose data
is directly impacted. This suggestion (b) might actually increase the
scope of such a section.

-- 
Kal Feher
Melbourne, Australia

---

From: Gurshabad Grover <[email-masked]>
Date: Wed, 7 Nov 2018 11:52:14 +0530

> of things "will" happen instead of "may" happen.

Thanks. Just wanted to clarify here to avoid any confusion: the HR
review is NOT the proposed text for the human rights considerations
section for the draft. I will be drafting a paragraph or two as my
proposition for the HRC section, and will be sharing it on this list.
Thanks for your feedback, I will take it into account when I draft it.

Thank you.
Gurshabad

---

From: "John Levine" <[email-masked]>
Date: 7 Nov 2018 14:43:07 +0700

Looks like I missed an exciting session.

>example, freedom from harassment seems like it would be a human right

Yes, that is in Article 12 of the Universal Declaration of Human
Rights.  I've pointed out more than once in HRPC sessions that there
are a lot more rights than the handful they like to think about.

I see no reason to add a human rights section to this specification,
and certainly nothing like the language they've proposed.

R's,
John

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 7 Nov 2018 08:52:33 +0100

>> example, freedom from harassment seems like it would be a human right

If we can make the link to this, I think we should document this in the considerations.

> are a lot more rights than the handful they like to think about.

I invited you to suggest additions to draft-irtf-hrpc-guidelines so we can add those considerations. I still think that would be very useful.

> and certainly nothing like the language they've proposed.

As Gurshabad said, no language has been proposed thusfar.

Happy to discuss!

Best,

Niels

---

From: "James Galvin" <[email-masked]>
Date: Fri, 16 Nov 2018 10:14:06 -0500

The chairs would like to summarize this thread as follows.

When specific text is proposed, then the working group will consider 
whether or not to create an HRPC section with that text in the document 
for which it is proposed.

In other words, the working group will consider an HRPC section on a 
case-by-case basis.  As there is no IETF consensus about such a 
requirement, the working group will consider each proposal as it would 
any other contribution to a document.

Thanks,

Antoin and Jim

On 7 Nov 2018, at 2:52, Niels ten Oever wrote:

>> In article 
>> <[email-masked]> 
>> you write:
> I invited you to suggest additions to draft-irtf-hrpc-guidelines so we 
> can add those considerations. I still think that would be very useful.
>