Re: Advertising WG adoption and WG LCs requests [was RE: Interim (and other) meeting guidelines versus openness, transparency, inclusion, and outreach]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I am having trouble getting my head around these two proposals.

P1 is to have a cross-WG list for all WG adoption calls.   That would probably be the only announce list that I would choose not to monitor.  If I care that much about the work progress in a WG, I should be monitoring the email lsit of that WG.  If I care that much about early stage drafts which may well be concerning, I should be monitoring all I-D announcements (which I do) so I have an idea of where concern is.  And if something is sufficiently concerning, I can start monitoring the relevant WG email list.

P2 is to have a cross-WG list for all WG last calls.  There are two problems with that.  First, that seems to assume that IETF last call doesn't work.  If we have that problem, we should be addressing it, not trying to work around it.   Second, technically and as a distinctly less matter, WGs are not required to have WG last calls, although I personally consider it a very good idea.

Yours,

Joel

On 7/18/2023 8:05 AM, mohamed.boucadair@xxxxxxxxxx wrote:
Hi all,

I also like these two proposals.

One variation would be to let the WG chairs specifically select a set of WGs to which the calls should be sent. For a recent document that involved up to 4 WGs (opsawg, add, dhcwg, radext), we managed to handle this by squatting the "Send notices to" to enclose the alias of a WG. That WG had the full visibility of the document that is developed in another WG.

For this comment from Carsten:

As a WG, I would not want people to jump on a document at this
stage with “doesn’t have an IANA Considerations section”, or with
a fine technical point that does indeed require WG work, but is
not a prerequisite to adopting it (collecting these points is
still useful, e.g., as github issues, but not as impediments to WG
adoption).
I assume that the same conventions for engaging in a call for adoption should be followed for ** all ** participants. Re-insist that a call for adoption is not a WGLC wouldn't harm though.

Cheers,
Med

-----Message d'origine-----
De : ietf <ietf-bounces@xxxxxxxx> De la part de Carsten Bormann
Envoyé : mardi 18 juillet 2023 12:22
À : Rob Wilton (rwilton) <rwilton=40cisco.com@xxxxxxxxxxxxxx>
Cc : ietf@xxxxxxxx
Objet : Re: Advertising WG adoption and WG LCs requests [was RE:
Interim (and other) meeting guidelines versus openness,
transparency, inclusion, and outreach]

On 2023-07-18, at 11:17, Rob Wilton (rwilton)
<rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote:
(1) I think that it would be helpful to have a mailing list
where notification of *all* WG adoption calls are made.
(2) I think that it would be helpful to have a separate mailing
list where notification of *all* WG last calls are made.

I like that a lot.

Probably these notifications need to have some boilerplate text,
in particular for WG adoption calls:

Documents at this stage are much more “private” to a WG than WGLC
documents.
Before a document made it to WGA call, a shared understanding may
have developed of what work (by the WG) is needed and how that
work would look like.
This is hard to transmit out of the WG at the time of an adoption
call.
(No, more work is not the answer.)

As a WG, I would not want people to jump on a document at this
stage with “doesn’t have an IANA Considerations section”, or with
a fine technical point that does indeed require WG work, but is
not a prerequisite to adopting it (collecting these points is
still useful, e.g., as github issues, but not as impediments to WG
adoption).

Grüße, Carsten
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux