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