Re: [Rfced-future] Issue 144

[John C Klensin <[e-mail]>]

--On Friday, January 7, 2022 09:08 +1300 Brian E Carpenter
<[e-mail]> wrote:

> On 07-Jan-22 06:12, Salz, Rich wrote:
>> *>* I suspect others may feel differently in that they don't
>> want this to be subject to changed IETF policies.
>> 
>> I'd really like to hear from people who feel this as to
>> what and why. I was just assuming this is like a WG in its
>> behavior, and perhaps my assumption is completely wrong.
 
> No, but it *isn't* an IETF WG and should be able to opt out of
> an IETF rule change that isn't appropriate. Analogy: each RFC
> stream decides its own IPR policy; the fact that streams have
> so far decided to follow the IETF policy doesn't change that
> independence.

Right.  But those streams have each made affirmative decisions
to do so, more or less on a policy by policy basis.

> Perhaps we can cover this with a blanket rule that the RSWG
> follows IETF rules and practices except when it doesn't. Only
> partly ;-).

Thanks for the smiley.  Just to illustrate why that is
important, ask yourself three questions:

(i) Would the RSWG be required to follow IETF rules even when
the IETF doesn't?  Take that bit about documents being ready
well before meetings as an example.  Or, to ask that question
differently, when IETF rules and practices are inconsistent,
which one should the RSWG be required to follow?

(ii) Are you prepared to precisely define, for the purposes of
this document and/or as something we should insist on having in
2026bis (which would then be a normative reference, possibly
freezing the publication of this document until severe climate
change and cooling reached a particular legendary warm place)
the boundaries of "IETF rules and practices"?  Presumably,
process BCPs count.  How about IESG statements?  Practices that
have often been followed in the absence of such statements?
And, before you answer that question, remember that actual
practices in WGs differ by Area.

(iii) If the IESG issues a new statement that replaces an older
one and changes some practice from what it was before (or
2418bis is published), does that automatically change the
practices of the RSWG, or that whatever this document says be
about rules and procedures applies as of the time of
publication, with  changes requiring RSWG action and/or RSAB
ratification?

So, yes, ":-)"

Again, what we need in terms of procedural rules isn't hard and
we have already given the RSWG/RSAB some discretion to tune them
as needed. Even if only for the pragmatic reason that any of the
above questions opens a can of worms, let's just write the rules
we need down. If anyone thinks it would be useful and there are
not really strong objections, we could note their similarity to
those of IETF WGs.   But then lets move on.

   best,
   john