Hi,
[belatedly, below]
On 7 Feb 2025, at 20:35, Alexis Rossi wrote:
On Tue, Feb 4, 2025 at 3:10 PM Colin Perkins <[email protected]>
wrote:
On 4 Feb 2025, at 1:59, Paul Hoffman wrote:
Greetings again. Alexis and I have combined my -00 draft with her
draft
on RPC responsibilities into a single draft, which is the -01 of my
earlier
draft. We have also incorporated most of the comments on our two
drafts
into this one. See below.
We recognize that there are some open issues (noted with %% markers
in
the draft), but we believe that this draft should be adopted by the
RSWG
and moved forward as a WG document.
One comment below, which shouldn’t prevent adoption if that’s the
consensus of the RSWG.
Section 3.2 discusses consumers of RFCs and says “consumers of RFCs
MUST
NOT be required or expected to become IETF/IRTF participants, but it
MAY be
recommended or suggested that they do so”. I don’t think this is
quite
correct, or at least it needs to be extended to recognise that
certain
activities are incompatible with being merely “a consumer” of
RFCs and
require a person to become a participant in IETF.
That is, “people who read RFCs to understand, implement, critique,
and
research the protocols, operational practices and other content”
remain
consumers of RFCs but if they wish to go beyond “reading” to
rather
“update” those RFCs, then they need to become IETF participants,
and the
draft needs to be clear on this.
Colin, do you have clearer wording to suggest for that?
The idea was to recognize that consumers and participants can
overlap, and
it's fine to encourage consumers to become involved as participants,
but
consumers must be able to use RFCs without becoming RFC/IETF experts.
Maybe to turn it around, I don't think there's any wording that
implies
they can participate in the process without being participants. But if
we
can make it clearer that would be great.
I’d suggest something like: “Consumers of RFCs are not required or
expected to become IETF or IRTF participants unless they wish to extend,
update, or modify an RFC”.
I’d also argue that reporting errata is part of the process of
updating an RFC since the errata reporter engages with the IETF, or
other stream, that reviews the errata report.
Colin
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
