Subject: [GROW] [Technical Errata Reported] RFC7948 (5366)

From: RFC Errata System <[email-masked]>
Date: Wed, 23 May 2018 10:04:39 -0700 (PDT)

The following errata report has been submitted for RFC7948,
"Internet Exchange BGP Route Server Operations".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5366

--------------------------------------
Type: Technical
Reported by: Greg Skinner <[email-masked]>

Section: 6.2

Original Text
-------------
[RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
           Estrin, "A Route Server Architecture for Inter-Domain
           Routing", 1995,
           <http://www.cs.usc.edu/assets/003/83191.pdf>.

Corrected Text
--------------
[RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
           Estrin, "A Route Server Architecture for Inter-Domain
           Routing", 1995,
<https://www.researchgate.net/
publication/
2297181_A_Route_Server_Architecture_for_Inter-Domain_Routing>

Notes
-----
The paper is no longer accessible from the www.cs.usc.edu site.  A related paper can be accessed at https://doi.org/10.1016/S0169-7552(98)00008-7 by those who are registered members or will pay for the paper.  It would be cited as:
[RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
                  Estrin, "A Route Server Architecture for Inter-Domain
                  Routing", Computer Networks and ISDN Systems, Volume 30,
                  Issue 12, 13 July 1998, Pages 1157-1174,
                  <https://doi.org/10.1016/S0169-7552(98)00008-7>.

Sorry, I had to split the link in the corrected text to satisfy the 72-character line length requirement in the corrected text.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7948 (draft-ietf-grow-ix-bgp-route-server-operations-05)
--------------------------------------
Title               : Internet Exchange BGP Route Server Operations
Publication Date    : September 2016
Author(s)           : N. Hilliard, E. Jasinska, R. Raszuk, N. Bakker
Category            : INFORMATIONAL
Source              : Global Routing Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 23 May 2018 18:09:08 +0100

This errata report isn't wrong, but belongs to a bigger category of 
problems relating to how the IETF handles third party references in RFCs.

It's unlikely that the researchgate url will be persistent in the longer 
term, at least any more than any other URL.

Nick

RFC Errata System wrote:
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 May 2018 13:16:16 -0400

> term, at least any more than any other URL.

​I marked it as Hold for Document Update -- this seems to be the "best" way
to annotate documents with things like this. ​

Thanks!
W

> > The paper is no longer accessible from the www.cs.usc.edu site.  A
> related paper can be accessed at
> https://doi.org/10.1016/S0169-7552(98)00008-7 by those who are registered
> members or will pay for the paper.  It would be cited as:
> > Sorry, I had to split the link in the corrected text to satisfy the
> 72-character line length requirement in the corrected text.
> >
> > Instructions:
> > -------------

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Job Snijders <[email-masked]>
Date: Wed, 23 May 2018 17:18:09 +0000

> problems relating to how the IETF handles third party references in

Yes. Until then I fear errata may be the only way to repoint URLs.

> It's unlikely that the researchgate url will be persistent in the
> longer term, at least any more than any other URL.

Maybe Greg Skinner will file a new errata when that happens? :-)

Kind regards,

Job

---

From: Greg Skinner <[email-masked]>
Date: Wed, 23 May 2018 15:52:58 -0700

Comments inline

> On May 23, 2018, at 10:18 AM, Job Snijders <[email-masked]> wrote:
> 

Agreed to both.

> Maybe Greg Skinner will file a new errata when that happens? :-)

Maybe. ;)  In the meantime, I have some general suggestions:

When giving a URI for a non-IETF publication (ie. something other than an RFC, BCP, etc.), the author should use the most “persistent” reference possible.  For example, the link that one should use for a published conference paper is that provided by the conference, if available.  The author should also note that signup or payment may be required to access the paper.  This suggestion could go in section 4.8.6.6 of RFC 7322, and the section could be renamed  Referencing Other Published Works.
Perhaps the idnits tool could be modified to perform a simply sanity check on (at least) the URIs of non-IETF publications.

Regards,
Greg

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 23 May 2018 19:12:41 -0400

The note that the paper was no longer accessible at the USC link was surprising.

Even more surprising was this note on a USC CS site:

https://www.cs.usc.edu/research/technical-reports/

Technical Reports
The Department of Computer Science no longer publishes technical reports to this website. All CS faculty and students should consider using a reputable computer science research archive to publish their reports. We recommend: arXiv Computer Science

A digital archive of all past reports previously hosted by the department will be made available in the near future.

And another page from the IT Services saying they were retiring their web hosting server because, after all, Wordpress is available.

On the basis of only a bit of research, the paper was indeed a USC technical report, it is still available at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.5118&rep=rep1&type=pdf, and the citeseerx sites says it was previously available at ftp://ftp.usc.edu/pub/csinfo/tech-reports/papers/95-603.ps.Z.  The ftp site still exists and answers pings, but does not answer ftp.  (It is a cname to the previously mentioned about to be retired web hosting server.)

A university abandoning publication of its research and, at least right now, not even sustaining the archive of its former publications.  Ugh.

—Sandy  

> On May 23, 2018, at 1:09 PM, Nick Hilliard <[email-masked]> wrote:
> 
> This errata report isn't wrong, but belongs to a bigger category of problems relating to how the IETF handles third party references in RFCs.
> 
> It's unlikely that the researchgate url will be persistent in the longer term, at least any more than any other URL.
> 
> Nick
> 
> RFC Errata System wrote:

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 24 May 2018 13:49:17 +0100

Sandra Murphy wrote:
> A university abandoning publication of its research and, at least
> right now, not even sustaining the archive of its former
> publications.  Ugh.

Long term document storage is hard.

Has the IETF looked at how to work around this problem?  If so, who is 
dealing with it?  If not, who should be dealing with it?  Should we take 
this up with the RFC Editor team?

Nick

---

From: heasley <[email-masked]>
Date: Thu, 24 May 2018 22:13:26 +0000

> Long term document storage is hard.

caching copies (with attribution) shouldnt be that difficult.

---

From: joel jaeggli <[email-masked]>
Date: Sat, 26 May 2018 09:22:28 -0700

On 5/23/18 10:16 AM, Warren Kumari wrote:
>
>
> On Wed, May 23, 2018 at 1:09 PM Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     longer
> ​I marked it as Hold for Document Update -- this seems to be the
> "best" way to annotate documents with things like this. ​
>
More generally the citation accurately describes the paper. At some
point in the future when we are long dead, it will still be a reference
to the paper.

Assuming that there is a method by which we can stably maintain
references to documents through URLs over the course of decades is
misguided.

>     > Reported by: Greg Skinner <[email-masked]
>     <mailto:[email-masked]>>
>     >
>     > Section: 6.2
>     >
>     > Original Text
>     > -------------
>     > The paper is no longer accessible from the www.cs.usc.edu
>     <http://www.cs.usc.edu> site.  A related paper can be accessed at
>     https://doi.org/10.1016/S0169-7552(98)00008-7
>     <https://doi.org/10.1016/S0169-7552%2898%2900008-7> by those who
>     are registered members or will pay for the paper.  It would be
>     cited as:
>     <https://doi.org/10.1016/S0169-7552(98)00008-7
>     <https://doi.org/10.1016/S0169-7552%2898%2900008-7>>.
>     >
>     > Sorry, I had to split the link in the corrected text to satisfy
>     the 72-character line length requirement in the corrected text.
>     >
>     > Instructions:
>     > -------------
>     > [email-masked] <mailto:[email-masked]>
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
>
>

---

From: Megan Ferguson <[email-masked]>
Date: Wed, 30 May 2018 22:59:45 -0700

All,

We consider errata to be errors at the time of publication.  We would not consider an errata report 
valid if the URL in question were functioning at the time of publication.  

>> Maybe Greg Skinner will file a new errata when that happens? :-)

Note that errata reports can be updated.  If this entry needs to be updated at some point, please 
contact the RFC Editor so we can provide access to the stream manager to review and update as needed.  
Please do not file a new erratum.  

Thank you.

RFC Editor/mf

On May 26, 2018, at 9:22 AM, joel jaeggli <[email-masked]> wrote:

>> ​I marked it as Hold for Document Update -- this seems to be the "best" way to annotate documents with things like this. ​
>> 
> More generally the citation accurately describes the paper. At some point in the future when we are long dead, it will still be a reference to the paper.
> 
> Assuming that there is a method by which we can stably maintain references to documents through URLs over the course of decades is misguided. 
> 
>> Thanks!
>> W
>> 
>>  
>> 
>> Nick
>> 
>> RFC Errata System wrote:
>> I don't think the execution is relevant when it was obviously a bad idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>>    ---maf
>> 
>>

---

From: Matt Griswold <[email-masked]>
Date: Thu, 31 May 2018 01:44:34 -0500

> caching copies (with attribution) shouldnt be that difficult.

Agreed, although, do we have metrics? This seems like a rather simple problem
to solve that has a huge outcome for future readers.