Subject: [Raw] Alvaro Retana's Discuss on draft-ietf-raw-ldacs-10: (with DISCUSS)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 18 Apr 2022 08:33:19 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-raw-ldacs-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-raw-ldacs/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[Authors:  Thank you for the work!  There's no action required from you.  My
opinion below is to be discussed with the IESG.]

I found this document very informative, and there is value in publishing it as
an RFC.  However, I don't believe it can pass the rough consensus bar set by
rfc8789 to become an IETF Stream RFC.

As mentioned by the Shepherd, this document is a "description by matter
specialists of an externally-defined link-layer".  The technology described is
an overview of work done elsewhere.  There was no discussion of the content on
the mailing list, which shows only two messages from non-authors: one asking
for more information; the reply was a pointer to the LDACS external
specification [1] -- the other was the single WGLC reply from the document
shepherd [2].

I want to discuss this question with the IESG:  Can the IETF reach rough
consensus on a document that describes someone else's technology?  This
document is akin to many others that have been published through the ISE as,
for example, a vendor's implementation of a specific protocol.

My opinion is that documents that describe someone else's technology cannot be
published as IETF RFCs given the requirement in rfc8789.

[1] https://mailarchive.ietf.org/arch/msg/raw/iyext4Ub8MgUjNYYPE7XOPpq1Y0
[2] https://mailarchive.ietf.org/arch/msg/raw/L-ByflWTn_3vcGC8NNfMO-blkJU