Subject: [Tools-discuss] RFC Email announcements

From: Tom Pusateri <[email-masked]>
Date: Tue, 1 Feb 2022 20:07:48 -0500

The following email was received this morning announcing a new RFC.

I think the link supplied to this document could be improved by 
referencing the rfc page instead of the info page.

https://www.rfc-editor.org/rfc/rfc9187.html

Here's why:

1. We should maximize the content and not the meta data. This is a 
common theme and I think we should be doing everything we can to 
emphasize the content we create and that is used by the most number of 
people and not the meta data that is used by a much smaller 
administrative group.

2. The rfc page contains a link at the top to the info page if that's 
what you really want but it probably isn't because there's already lots 
of meta data in the email.

3. If you're really into meta-data, the top of the rfc page also 
contains a link to the datatracker. :)

Thanks,
Tom

-------- Forwarded Message --------
Subject: RFC 9187 on Sequence Number Extension for Windowed Protocols
Date: Mon, 31 Jan 2022 23:17:49 -0800 (PST)
From: [email-masked]
To: [email-masked], [email-masked]
CC: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

                 RFC 9187

         Title:      Sequence Number Extension for Windowed Protocols 
       Author:     J. Touch
         Status:     Informational
         Stream:     Independent
         Date:       January 2022
         Mailbox:    [email-masked]
         Pages:      10
         Updates/Obsoletes/SeeAlso:   None

         I-D Tag:    draft-touch-sne-02.txt

         URL:        https://www.rfc-editor.org/info/rfc9187

         DOI:        10.17487/RFC9187

Sliding window protocols use finite sequence numbers to determine
segment placement and order. These sequence number spaces wrap around
and are reused during the operation of such protocols. This document
describes a way to extend the size of these sequence numbers at the
endpoints to avoid the impact of that wrap and reuse without
transmitting additional information in the packet header. The
resulting extended sequence numbers can be used at the endpoints in
encryption and authentication algorithms to ensure input bit patterns
do not repeat over the lifetime of a connection.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   https://www.ietf.org/mailman/listinfo/ietf-announce
   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Feb 2022 14:59:13 +1300

> https://www.rfc-editor.org/rfc/rfc9187.html

Disagree. Here's why:

1. The info page shows the current status, e.g. Historic, Updated By, and so on. We need people to be aware of the status before reading or citing an RFC. For example, it tells me that RFC9817 is not from the IETF.
It tells me that RFC2460 is obsolete.

That is not an "administrative" matter. It's what you need to know before reading the text.

2. We probably agree that the HTML is the best one to actually read, but opinions may differ.

     Brian

> ___________________________________________________________
> Tools-discuss mailing list - [email-masked]
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: [email-masked]
> * Report tools.ietf.org bugs to: [email-masked]
> * Report all other bugs or issues to: [email-masked]
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
>

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 1 Feb 2022 21:24:27 -0500

That’s in the email. I’ve already decided I wanted to read it when I clicked on the link.

We publish documents not meta data.

And my preference would have the rfc links be in the document References too (not the info links).

Tom

> On Feb 1, 2022, at 8:59 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Feb 2022 15:47:47 +1300

Tom,

The email is transitory; the point is to use the info URL as the primary reference, for the reasons I gave. That's what the RFC Editor service has 
decided to do, and I fully support that choice.

Regards
    Brian

---

From: Jay Daley <[email-masked]>
Date: Wed, 2 Feb 2022 16:02:50 +1300

In previous discussions on this same point a number of people have noted that this is a not a binary choice as the landing page can be both the info page and show the document as well.  The discussion then normally expands to cover individual preferences on what format is displayed by default and the possibility of storing a preference.  That then can take a detour into the use of cookies for storing preferences and a reminder that this is expressly covered in the Privacy Statement.  A point is sometimes raised about how to avoid a cluttered page if it is both an info page and a document page, to which others then reply that this is trivial with Javascript while providing a perhaps cluttered fallback for those who do not wish to enable Javascript.

All need now is for the RFC Editor Future Program to complete so that we can all understand the new mechanism for proposing, agreeing and implementing such changes.

Jay

> On 2/02/2022, at 3:47 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Tom,
> 
> The email is transitory; the point is to use the info URL as the primary reference, for the reasons I gave. That's what the RFC Editor service has decided to do, and I fully support that choice.
> 
> Regards
>   Brian
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]