Re: [rfc-i] archiving outlinks in RFCs

Hi all,

A comment below on what is considered an erratum--

On 4/28/23 3:28 AM, Jay Daley wrote:
>
>
>> On 28 Apr 2023, at 09:22, Brian Carpenter 
>> <brian.e.carpenter@gmail.com> wrote:
>>
>> +1 to Ted except that sometimes errata are simply ignored for 
>> literally years. That's why I suggest a timeout after which the 
>> redirect is atomatically approved.
>
> The more important point is that errata are not applied to RFCs as 
> RFCs are unchanging.  Using solely the errata mechanism would mean 
> someone you encountered a broken link, having to explicitly select the 
> "show with errata" feature to find the new link.
>
> So while the errata mechanism is close to what we want, in my view 
> it’s not enough.  (There’s also a principle debate on whether or not a 
> dead link is actually an erratum).
[JM]  The current errata reporting procedure [1] states, "Errata reports 
should only be filed for issues that would have been considered errors 
at the time the RFC was published." A link that breaks sometime after 
the RFC is published doesn't technically qualify; however, I agree that 
they are annoying and it would be helpful to readers to provide updated 
link info.

Best regards,
Jean

[1] https://www.rfc-editor.org/how-to-report/

>
> I don’t what stopping us from creating a new process specifically for 
> broken links
>
> - bot checks links and finds broken one, auto-generates a report
> - report is looked at by appropriate person/body who decide on 
> replacement link target (if there is one)
> - HTML version of the RFC is updated to point to new target
>
> Jay
>
>
>>
>> (via tiny screen & keyboard)
>> Regards,
>>         Brian Carpenter
>>
>> On Fri, 28 Apr 2023, 20:03 Ted Hardie, <ted.ietf@gmail.com> wrote:
>>
>>     On Thu, Apr 27, 2023 at 9:10 PM Alexis Rossi
>>     <rsce@rfc-editor.org> wrote:
>>
>>         It seems like using the errata system would maybe be a more
>>         haphazard method of fixing broken links over time, since it
>>         relies on humans to notice the original link is dead, report
>>         that as an errata, and then another human to check and
>>         approve it. Unless the proposal is to have a bot that files
>>         errata when links die (and then there’s just one human step
>>         to approve)?
>>
>>
>>     Yes, sorry that was clear.  Essentially, the steps I propose:
>>
>>     On RFC publication, archive the outlink.
>>
>>     Run a periodic check on the status of the links in each RFC.
>>
>>     When one is determined to be unavailable, file an erratum
>>     mechanically
>>
>>     The community that would normally determine erratum validity
>>     examines the issue and determines the next step, which might be
>>     one of:
>>
>>     1) The erratum is approved and lists the archived information as
>>     the target for approval on document update
>>     2) The erratum is approved a different URL is listed as the
>>     target for approval on document update (e.g. the
>>     ieee.example/standards/08675 replacing ieee.example/standards/8675
>>     3) The erratum is rejected as the error was transient or will be
>>     corrected by the origin (where these are sibling SDOs, we
>>     generally have a way to reach out to them for this information).
>>
>>     The normal erratum process is then used to provide this
>>     information to the community (either separately or in-line,
>>     depending on the method they choose).
>>
>>     The advantage of this approach is that we are using community
>>     approved processes in a pretty easily understood way.  We can
>>     also use the same process when the link is live but something
>>     like a paywall has changed the state of availability.  That's not
>>     something we can likely identify mechanically, but we can re-use
>>     this set of steps.
>>
>>     Sorry that this wasn't clearer before.
>>
>>     regards,
>>
>>     Ted
>>
>>>         On Apr 27, 2023, at 1:40 AM, Ted Hardie <ted.ietf@gmail.com>
>>>         wrote:
>>>
>>>         On Wed, Apr 26, 2023 at 6:12 PM Michael Richardson
>>>         <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>> wrote:
>>>
>>>
>>>             Ted Hardie <ted.ietf@gmail.com> wrote:
>>>                 > I agree with Ekr that this is problematic, but my
>>>             concern is with external
>>>                 > links to other standards.  If I replace a link to
>>>             https://ieee.example/876.1
>>>                 > to an archive link like
>>>                 >
>>>             https://archivesite.example/see?https_ieee_example/876.1_retrieved_the_day_of_publication
>>>                 > then ieee.example has no chance to use its own
>>>             redirects or tombstones to
>>>
>>>             It also keeps ieee.example from replacing the link that
>>>             we were using with a
>>>             link that goes through a paywall.
>>>
>>>             (Which, btw, DOES HAPPEN regularly)
>>>
>>>
>>>         I think this would also be grounds for filing an erratum. 
>>>         But my basic point remains that the erratum process triggers
>>>         the right thing: discussion among the folks within the IETF
>>>         who are responsible for the relevant RFC.  There are several
>>>         different "correct" responses depending on the
>>>         circumstances, and they are the right folks to make the
>>>         decision.  We already have a way to indicate that there are
>>>         errata and/or display them in line.  We can use that here,
>>>         rather than trying to decide in advance.
>>>
>>>         regards,
>>>
>>>         Ted
>>>
>>>
>>>             --
>>>             Michael Richardson <mcr+IETF@sandelman.ca
>>>             <mailto:mcr%2BIETF@sandelman.ca>>  . o O ( IPv6 IøT
>>>             consulting )
>>>                        Sandelman Software Works Inc, Ottawa and
>>>             Worldwide
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         rfc-interest mailing list
>>>         rfc-interest@rfc-editor.org
>>>         https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>>
>>     _______________________________________________
>>     rfc-interest mailing list
>>     rfc-interest@rfc-editor.org
>>     https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>>
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest@rfc-editor.org
>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>
> -- 
> Jay Daley
> IETF Executive Director
> exec-director@ietf.org
>
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest