Re: Proposed IESG statement on referencing documents behind a paywall

[Suresh Krishnan <[e-mail]>]

Hi Michael,

> On Jun 12, 2019, at 9:17 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Suresh Krishnan <[e-mail]> wrote:
>> In the past we have dealt with a few drafts that have had normative
>> references to paywalled documents and we have dealt with them on a
>> case-by-case basis (usually during or after IETF last call). In order
>> to get the working groups involved earlier in the process, the IESG is
>> working on issuing a statement on how to deal with such drafts and we
>> would greatly appreciate input from WG chairs on this topic. This is
>> the proposed text of the statement
> 
> Thank you for taking this on.
> I hope that this means that the open-stand.org effort will also get rebooted,
> although I recognize that's more an ISOC/LLC thing.
> 
>> 1. The WG MUST be explicitly informed of any such normative reference
>> and the WG MUST reach consensus that it is acceptable. The
>> document shepherd MUST include this information in the shepherd
>> writeup.
> 
> I find this acceptable first step of the process.
> 
> I'm not sure what the WG should do when I say
>  "Please take this work out of the IETF if I can't implement
>   or validate an implementation without document FOO”

I would think it will be up to the chairs to check for consensus to see how to proceed. I have seen some ipr declarations destroy drafts and some that barely register an impact. I would think this will end up the same way depending on how the WG feels about the reference.

> 
> And, btw, I don't consider a non-paywall with some https://tosdr.org/
> click through.  I want a URL for the document. When I click on it, I get the
> document.  When I put a #foobar on the URL, I can reference a section of it,
> and when I copy and paste from it into an email, I'm not violating their
> copyright.

I get your point but I have also seen people who hold the exact opposite viewpoint where financial considerations were more important to them. RFC2026 is pretty liberal about what it considers open standards (Section 7) and we are not trying to redefine it here.

Thanks
Suresh