Thanks, Adrian
Looking back at a lot of (multicast) RFCs that started as experimental i guess
i had tied
the meaning of the word too much to "blessed by IETF for further adoption", but
it
makes a lot of sense to apply it also to other (non IETF blessed/validated)
experiments.
Just never thought of it that way.
Although: In that case though, i would love to see even more documentation of
environmental
aspects such as implementation information.
Sure, removing implementation and any other process-how-we-got-here sections
from
RFC is fine. The only gotcha i observed when just moving a draft into the RFC
editor queue
was that my AD (also here on the thread ;-) felt that it was not even
appropriate to
leave in the RFC a breadcrumb sentence pointing to the existance of (outdated
or not) additional
information in the last draft. I think such a breadcrub sentence would be a
perfect
way to justify the effort to invest cycles into good tracking of process data
during
the development. And reduce the amount of pain having to go back and sift such
info
oout of mailing list archives (if it's there at all).
Cheers
Toerless
On Mon, Mar 01, 2021 at 03:47:38PM -0000, Adrian Farrel wrote:
> Hi Toerless,
>
> >> Just to re-assert that the Independent Submissions Stream can publish
> Informational
> >> and Experimental RFCs.
> >
> > Just if its approriate to ask on a list where i could probably wade
> through rfcs to find
> > the answer: Whats the relevance/differentiation of "experimental" for
> independent
> > stream ?
>
> That's a question for the ISE, I think.
> The answer is that the definition of the RFC categories is immutable across
> the various RFC streams.
> The difference is that "Informational" provides information, while
> "Experimental" describes an on-going experiment (not usually an experiment
> that has already completed).
> The Independent Stream can only publish Informational, Experimental, and
> Historic RFCs.
>
> > Other than that:
>
> I leave the other questions to the discussion among the authors, but you
> might find RFC 7942 useful and note that it recommends removing reports of
> implementation status from RFCs before publication because the information
> rarely retains currency (wiki pages, OTOH, can be helpful).
>
> Cheers,
> Adrian
>
> > - Is there anywhere information about the available SOCK implementations
> sufficiently
> > detailed to understand their ability and use-case benefits to
> interoperate (between
> > client SDK/shim-library and server ?
> >
> >- For those existing or planned future implementations, is it possible to
> collect insight
> > into how eager the implementers would be to adopt the draft proposed
> functionality ?
> >
> >- For any implementer/implementations showing interest in adoption, where
> their
> > names collected ?
> >
> > If this did all happen in some discussions on int-area, i would still
> prefer to see this
> > salient information collected in a document. Even if it might not be this
> draft, but an -ops
> > draft, but especially when this goes ISE, it should be much less a problem
> to have
> > actual dadoption relevant information in a doc as opposed to jus the bare
> protocol details.
> >
> > Even if his is built on the push model of "standardize it and they
> (implementers) will come",
> > it would (at last for me) still be highly useful to see a list of
> implementations, and whether
> > or not the authors of this document reached out to the implemenations to
> query about the
> > interest in this 'extension/version'.
--
---
[email protected]
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
