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

[Erik Kline <[e-mail]>]

Even though I just balloted No Objection, I find myself somewhat
sympathetic to Alvaro's observation here.  I do think this document is well
worth publishing.  However, its relationship to IETF work is not entirely
clear:

  * Section 6 Requirements are not requirements for raw (nor any other IETF
work) but more requirements for LDACS itself.

  * The IPv6, LISP, and other IETF technology parts all appear to be
largely "TBD" at the moment.

However, I don't know enough about raw to have a terribly strong feeling at
the moment, and it seems LDACS did get itself a mention in the charter...
(not that that's terribly conclusive one way or the other).

:-/

On Mon, Apr 18, 2022 at 2:37 PM John Scudder <jgs=
[e-mail]> wrote:

> Hi, Alvaro.
>
> I’m a little unclear as to your reasoning, let me see if I have it right:
>
> 1. You’re making the assertion that it’s not possible for the IETF to
> “reach rough consensus on a document that describes someone else's
> technology”. As I understand it, you’re not citing an authority for this —
> you just think it’s self-evident, like the statement “rain doesn’t fall
> up”.
>
> 2. Following from the previous premise, you point out that if that’s the
> case, RFC 8789 says we can’t advance the document.
>
> So the discussion we (the IESG) need to have is whether #1 is true. If
> there were some authority that said as much, that would make the argument
> open-and-shut, but if there’s not (and I’m not aware of one), it may come
> down to a matter of opinion, which isn’t very satisfying.
>
> In any case we agree that the document should be published in some stream.
>
> Thanks,
>
> —John
>
> > On Apr 18, 2022, at 11:33 AM, Alvaro Retana via Datatracker <
> [e-mail]> wrote:
> >
> >
> > 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!XwKY_jfrpG5svnN1jiQ4u_aggXi4Lwk0Go_0oBNMG5XuDHnDkQKcbAPjGUZvIA$
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-raw-ldacs/__;!!NEt6yMaO-gk!XwKY_jfrpG5svnN1jiQ4u_aggXi4Lwk0Go_0oBNMG5XuDHnDkQKcbAM0naAhvA$
> >
> >
> >
> > ----------------------------------------------------------------------
> > 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/raw/iyext4Ub8MgUjNYYPE7XOPpq1Y0__;!!NEt6yMaO-gk!XwKY_jfrpG5svnN1jiQ4u_aggXi4Lwk0Go_0oBNMG5XuDHnDkQKcbAO5FpQ62A$
> > [2]
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/raw/L-ByflWTn_3vcGC8NNfMO-blkJU__;!!NEt6yMaO-gk!XwKY_jfrpG5svnN1jiQ4u_aggXi4Lwk0Go_0oBNMG5XuDHnDkQKcbAOCzEgDOw$
> >
> >
> >
> >
> >
>
>