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 > > > James Gould > Distinguished Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 11/7/18, 12:02 AM, "regext on behalf of Niels ten Oever" > <regext-boun...@ietf.org on behalf of li...@digitaldissidents.org> wrote: > > On 11/6/18 5:50 PM, Gould, James wrote: > > 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. > > > > > > > > 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 > > > > > > > > > > — > > > > JG > > > > > > > > > > > > > > > > James Gould > > > > Distinguished Engineer > > > > jgo...@verisign.com > > > > > > > > 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" > <regext-boun...@ietf.org on behalf of i...@feherfamily.org> wrote: > > > > > > > > > > > > On 6/11/18 10:52 pm, Niels ten Oever wrote: > > > > > On 11/6/18 1:00 PM, Hollenbeck, Scott wrote: > > > > >>> On Nov 6, 2018, at 4:32 PM, Niels ten Oever > <li...@digitaldissidents.org> wrote: > > > > >>> > > > > >>> > > > > >>> > > > > >>> On 11/6/18 9:59 AM, Hollenbeck, Scott wrote: > > > > >>>>> -----Original Message----- > > > > >>>>> From: Niels ten Oever <li...@digitaldissidents.org> > > > > >>>>> Sent: Tuesday, November 06, 2018 3:36 AM > > > > >>>>> To: Hollenbeck, Scott <shollenb...@verisign.com>; > 'regext@ietf.org' > > > > >>>>> <regext@ietf.org> > > > > >>>>> Subject: [EXTERNAL] Re: [regext] "Considerations" Sections > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> On 11/6/18 9:22 AM, Hollenbeck, Scott wrote: > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: regext <regext-boun...@ietf.org> On Behalf Of Niels > ten Oever > > > > >>>>>>> Sent: Tuesday, November 06, 2018 3:07 AM > > > > >>>>>>> To: regext@ietf.org > > > > >>>>>>> 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, > > > > 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. > > > > >>>>> 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. > > > > > > > > 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. > > > > > > > > > Best, > > > > > > > > > > Niels > > > > > > > > > -- > > > > Kal Feher > > > > Melbourne, Australia > > > > > > > > > > > > > > > > > > _______________________________________________ > > regext mailing list > > regext@ietf.org > > 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 > > _______________________________________________ > regext mailing list > regext@ietf.org > 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
