Subject: [Manycouches] BCP # for draft-ietf-shmoo-cancel-meeting?

From: Martin Duke <[email-masked]>
Date: Mon, 4 Oct 2021 08:21:28 -0700

Hi SHMOO,

draft-ietf-shmoo-cancel-meeting (soon to be RFC 9137) needs a BCP number.

There are two sensible options I am aware of:
- Stand by itself as BCP 235.
- Be grouped into BCP 226 <https://www.rfc-editor.org/info/bcp226>, which
is all about meeting policies.

I have no strong opinion on this, but if forced to decide I'd put it in
with 226. I'm happy to receive suggestions on this topic (including some
*other* BCP in which this clearly fits.)

Thanks
Martin

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Oct 2021 14:32:54 -0400

> is all about meeting policies.

I looked, and BCP226 has:

* IETF Plenary Meeting Venue Selection Process
* High-Level Guidance for the Meeting Policy of the IETF

    > *other* BCP in which this clearly fits.)

and I agree with you, that BCP226 is the right place to put this document.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 4 Oct 2021 15:16:05 -0500

> and I agree with you, that BCP226 is the right place to put this document.
+1

Behcet

> _______________________________________________
> Manycouches mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manycouches
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Oct 2021 14:59:41 +0200

Sounds reasonable to group together these documents in a common unique
place to find guidance about a same high-level topic.

One point I'd mention too is that, this being the first time I hear
about several RFCs being 'in' a single BCP, I wonder whether there will
be an undesirable situation in which people refer to BCP226 and actually
talk about another RFC than this cancel rule, thus a potential place for
confusion.  Or maybe it's just me discovering this 'in' relationship for
BCP RFCs.

Alex

Le 04/10/2021 à 17:21, Martin Duke a écrit :
> There are two sensible options I am aware of: - Stand by itself as
> BCP 235. - Be grouped into BCP 226
> <https://www.rfc-editor.org/info/bcp226>, which is all about meeting
> policies.
> 
> I have no strong opinion on this, but if forced to decide I'd put it
> in with 226. I'm happy to receive suggestions on this topic
> (including some /other/ BCP in which this clearly fits.)
> 
> Thanks Martin
> 
> _______________________________________________ Manycouches mailing
> list [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Tue, 5 Oct 2021 09:14:42 -0400

Yes, there are a number of BCPs (and STDs) that consist of multiple
RFCs.  Another example is BCP 14, which used to be RFC 2119 and is now
that plus the update in RFC 8174 -- current use of BCP 14 needs both.

Citing the BCP (or STD) ensures a reference to whichever version is
current at the time of reading; citing the individual RFC(s) creates a
reference to what was current at the time of writing.  Which you want
to refer to will determine how you cite it.

Barry

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Oct 2021 13:15:25 +0000

>  Or maybe it's just me discovering this 'in' relationship for BCP RFCs.

Seems like that is the case.  I guess you've never clicked on any of the links in the Note Well (https://www.ietf.org/about/note-well/) since the first three BCP's are "groups"

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Oct 2021 19:50:09 +0200

Le 05/10/2021 à 15:15, Salz, Rich a écrit :
> Seems like that is the case.  I guess you've never clicked on any of
> the links in the Note Well (https://www.ietf.org/about/note-well/)
> since the first three BCP's are "groups"

Maybe there is a difference between groups.  The Note Well talks about 
BCP 79 first, if that is what you meant; this BCP79 seems to be a single 
RFC (8179) and, true, it obsoletes two other RFCs.  It is a group of a 
single RFC and many other obsoleted RFCs.

That kind of 'group' BCP79 seems different than this kind of BCP226 
which truly is made of several RFCs all valid at the same time.

In this kind of BCP226 group of all up-to-date RFCs (no obsolescence) 
one would make sure that one RFC is not telling something aspect 
contrary of another RFC in same group.  I.e. 
draft-ietf-shmoo-cancel-meeting should not say something contrary to 
RFC8718 or to RFC8719.

That is something difficult to assess, at least because there are said 
things and silent things.

When RFC8718 tells there are 3 criteria to meet (section 3.1 "Mandatory 
Criteria"), and is silent about criteria not to meet, then that might 
become an issue with consistency with draft-ietf-shmoo-cancel-meeting. 
To address it, maybe an Errata to RFC8718 could be made to add a 
reference to this draft-ietf-shmoo-cancel-meeting.

Or maybe this has already been addressed, or maybe it represents too 
much work to struggle with... not wanting to detail things to infinity 
either.

Alex