Subject: [Gendispatch] IETF 109 minutes + chair summary

From: Francesca Palombini <[email-masked]>
Date: Fri, 5 Feb 2021 15:41:22 +0000

Hi all,

Apologies for the delay getting this email out.
As you might have seen, the minutes from IETF 109 have been posted: https://datatracker.ietf.org/meeting/109/materials/minutes-109-gendispatch-00 If you have any corrections, please let me know.

Here comes my personal summary of the discussion on draft-carpenter-gendispatch-rfc7221bis so far. Please note that this is my personal understanding, I haven't had the chance to get it approved by my co-chair, but didn't want to delay any longer. I am looking for answers to the questions below, as well as comments if you believe I missed or mischaracterized anything.

---
Firstly, there was rough consensus in the room that, as it stands now, the working group procedures in the IETF are not clearly described. This ambiguity is reflected in RFC 7221. It is hard to find information about the practical ways of working in IETF wgs, which is a problem especially for getting new people actively involved.
I understood from the discussion in the room that there was rough consensus that we need to do something about it.

The authors of draft-carpenter-gendispatch-rfc7221bis have written an update to RFC 7221 (that would obsolete it) with the intent to clarify the existing information. If this document (7221bis) was to move forward, I heard most voices supporting this document being published want it to move forward as informational. A couple of people have expressed the need for a BCP, but from my understanding this draft would not be the start of such a BCP.

Objections to this document being published as informational were raised, stating that too often informational RFCs are taken as rules. There was strong voices in the room in  both directions about if any text would be helpful to clarify that this is a purely descriptive document, not to be taken as guidelines or rules.

I want to note that this is a much bigger conversation than the draft that we are trying to dispatch, but we can't really recommend one outcome for this particular document without considering the bigger picture. As a result, my first recommendation would be to set up a mailing list to have a venue to continue this discussion on the content of 7221bis - clarifying IETF ways of working. 

Possible dispatching outcomes (in no particular order) that are, in my opinion, the most likely outcomes based on the discussion are described below. I added some questions, which are of course conditional on the outcome.

1) Publish the draft as informational

      - work on the text in the newly created list, but also get feedback from wg chairs list and ietf@ietf
            QUESTION1: afaict this was not addressed during the meeting - does anybody feel like a wg should be created for this? (as opposed to AD sponsored, and advertised on the lists above) 

      - be careful that the document is clearly descriptive and does NOT provide guidance
            QUESTION2: I want to re-iterate the question to those who objected to this outcome - knowing that there is already a note in the introduction about it - is there any additional modifications that would make you comfortable with this outcome?

      - after publishing, point to it from the website, training etc.

2) Do not publish this draft, but rather treat the text like the Tao, publish it on the website (for ex ietf.org "how we work"). 

      - the text still needs review. The newly created list could be used, plus updates could be made on the wg-chairs and ietf@ietf lists.

      - We would need to make sure duplicated info is not happening (7221 vs website)
            * During the meeting the question came up if the IESG could mark RFC 7221 as historic (if we can do that for informational), possibly linking from the datatracker to the website. We could follow the example of RFC 6722 for the Tao, and obsolete RFC 7221 with such a document, while pointing to the webpage.
            QUESTION3: To authors and those who preferred updating RFC 7221 with clarified text, would this be an acceptable alternative?

Additionally (and out of scope of our dispatching discussion) I wanted to note that it was brought up that there might be need to revise RFC 2418. This could be the BCP which was mentioned above. 
---

Thanks,
Francesca

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Feb 2021 09:47:51 +1300

> 2) Do not publish this draft, but rather treat the text like the Tao, publish it on the website (for ex ietf.org "how we work")

I have some sympathy for this, BUT it seems to me that it is rather too late for that discussion, which should have applied when RFC7221 was under consideration. One could make a similar argument for RFC7282 ("On Consensus and Humming in the IETF") and probably some others. So a consistent proposal would be:
a) identify all the RFCs of this type (not BCP rules, but friendly advice).
b) review them all for errors & omissions
c) make them all Historic RFCs
d) add all the material either into the Tao or in How we Work.

(Note for Greg: the Tao really should be cross-linked from How we Work.)

So in answer to

> QUESTION3: To authors and those who preferred updating RFC 7221 with clarified text, would this be an acceptable alternative?

Yes, as part of a wider initiative, because it isn't just this RFC. And I'd point at the EMO Directorate as the responsible body. If they won't take it on, I think it needs a dedicated mailing list as a focus (probably not a WG, but that's for the incoming General AD to decide).

Regards
   Brian Carpenter

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Feb 2021 12:52:17 -0800

On Fri, Feb 5, 2021 at 12:48 PM Brian E Carpenter <
[email-masked]> wrote:

> > 2) Do not publish this draft, but rather treat the text like the Tao,
> publish it on the website (for ex ietf.org "how we work")
>
> I have some sympathy for this, BUT it seems to me that it is rather too
> late for that discussion, which should have applied when RFC7221 was under
> consideration. One could make a similar argument for RFC7282 ("On Consensus
> and Humming in the IETF") and probably some others. So a consistent
> proposal would be:
> (Note for Greg: the Tao really should be cross-linked from How we Work.
>

Brian,

This sounds like generally a great way forward. One thing I would like to
make sure is that we properly label these when we pull them into the Tao or
the like. In particular, as I mentioned at the meeting, 7278 is explicitly
framed as one opinion; as there are pieces of it that I disagree with I
wouldn't want to see it accidentally turned into the IETF's opinion without
the appropriate level of consensus determination.

-Ekr

So in answer to
>
> > QUESTION3: To authors and those who preferred updating RFC 7221 with
> clarified text, would this be an acceptable alternative?
>
> Yes, as part of a wider initiative, because it isn't just this RFC. And
> I'd point at the EMO Directorate as the responsible body. If they won't
> take it on, I think it needs a dedicated mailing list as a focus (probably
> not a WG, but that's for the incoming General AD to decide).
>
> Regards
>    Brian Carpenter
>
> > As you might have seen, the minutes from IETF 109 have been posted:
> https://datatracker.ietf.org/meeting/109/materials/minutes-109-gendispatch-00
> If you have any corrections, please let me know.
> >
> > Here comes my personal summary of the discussion on
> draft-carpenter-gendispatch-rfc7221bis so far. Please note that this is my
> personal understanding, I haven't had the chance to get it approved by my
> co-chair, but didn't want to delay any longer. I am looking for answers to
> the questions below, as well as comments if you believe I missed or
> mischaracterized anything.
> >
> > ---
> > Firstly, there was rough consensus in the room that, as it stands now,
> the working group procedures in the IETF are not clearly described. This
> ambiguity is reflected in RFC 7221. It is hard to find information about
> the practical ways of working in IETF wgs, which is a problem especially
> for getting new people actively involved.
> > I understood from the discussion in the room that there was rough
> consensus that we need to do something about it.
> >
> > The authors of draft-carpenter-gendispatch-rfc7221bis have written an
> update to RFC 7221 (that would obsolete it) with the intent to clarify the
> existing information. If this document (7221bis) was to move forward, I
> heard most voices supporting this document being published want it to move
> forward as informational. A couple of people have expressed the need for a
> BCP, but from my understanding this draft would not be the start of such a
> BCP.
> >
> > Objections to this document being published as informational were
> raised, stating that too often informational RFCs are taken as rules. There
> was strong voices in the room in  both directions about if any text would
> be helpful to clarify that this is a purely descriptive document, not to be
> taken as guidelines or rules.
> >
> > I want to note that this is a much bigger conversation than the draft
> that we are trying to dispatch, but we can't really recommend one outcome
> for this particular document without considering the bigger picture. As a
> result, my first recommendation would be to set up a mailing list to have a
> venue to continue this discussion on the content of 7221bis - clarifying
> IETF ways of working.
> >
> > Possible dispatching outcomes (in no particular order) that are, in my
> opinion, the most likely outcomes based on the discussion are described
> below. I added some questions, which are of course conditional on the
> outcome.
> >
> >       - work on the text in the newly created list, but also get
> feedback from wg chairs list and ietf@ietf
> >             QUESTION1: afaict this was not addressed during the meeting
> - does anybody feel like a wg should be created for this? (as opposed to AD
> sponsored, and advertised on the lists above)
> >
> >             QUESTION2: I want to re-iterate the question to those who
> objected to this outcome - knowing that there is already a note in the
> introduction about it - is there any additional modifications that would
> make you comfortable with this outcome?
> >
> > 2) Do not publish this draft, but rather treat the text like the Tao,
> publish it on the website (for ex ietf.org "how we work").
> >
> >       - the text still needs review. The newly created list could be
> used, plus updates could be made on the wg-chairs and ietf@ietf lists.
> >
> >             * During the meeting the question came up if the IESG could
> mark RFC 7221 as historic (if we can do that for informational), possibly
> linking from the datatracker to the website. We could follow the example of
> RFC 6722 for the Tao, and obsolete RFC 7221 with such a document, while
> pointing to the webpage.
> >             QUESTION3: To authors and those who preferred updating RFC
> 7221 with clarified text, would this be an acceptable alternative?
> >
> > Additionally (and out of scope of our dispatching discussion) I wanted
> to note that it was brought up that there might be need to revise RFC 2418.
> This could be the BCP which was mentioned above.
> > ---
> >
> > Thanks,
> > Francesca
> >
>
> --
> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 5 Feb 2021 20:58:12 +0000

>So a consistent proposal would be:

This seems like a really good idea. In addition to ekr's point, we should also explain why the source documents are HISTORIC now.

(Bikeshed: I prefer not adding more context to the Tao)

>    (Note for Greg: the Tao really should be cross-linked from How we Work.)

I suggest you ping him directly to make sure he sees it.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 7 Feb 2021 10:16:14 +1300

7278? I don't think so...

We could at least build a list of this class of RFC to size the problem.

Regards
   Brian

On 06-Feb-21 09:52, Eric Rescorla wrote:
> 
> 
> On Fri, Feb 5, 2021 at 12:48 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > 2) Do not publish this draft, but rather treat the text like the Tao, publish it on the website (for ex ietf.org <http://ietf.org> "how we work")
> 
> This sounds like generally a great way forward. One thing I would like to make sure is that we properly label these when we pull them into the Tao or the like. In particular, as I mentioned at the meeting, 7278 is explicitly framed as one opinion; as there are pieces of it that I disagree with I wouldn't want to see it accidentally turned into the IETF's opinion without the appropriate level of consensus determination.
> 
> -Ekr
> 
>     So in answer to
> 
>     > 2) Do not publish this draft, but rather treat the text like the Tao, publish it on the website (for ex ietf.org <http://ietf.org> "how we work").
>     >
>     [email-masked] <mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Feb 2021 13:22:49 -0800

> 7278? I don't think so...

Sorry. 7282.

-Ekr

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     > 2) Do not publish this draft, but rather treat the text like the
> Tao, publish it on the website (for ex ietf.org <http://ietf.org> "how we
> work")
> >
> >     I have some sympathy for this, BUT it seems to me that it is rather
> too late for that discussion, which should have applied when RFC7221 was
> under consideration. One could make a similar argument for RFC7282 ("On
> Consensus and Humming in the IETF") and probably some others. So a
> consistent proposal would be:
> > This sounds like generally a great way forward. One thing I would like
> to make sure is that we properly label these when we pull them into the Tao
> or the like. In particular, as I mentioned at the meeting, 7278 is
> explicitly framed as one opinion; as there are pieces of it that I disagree
> with I wouldn't want to see it accidentally turned into the IETF's opinion
> without the appropriate level of consensus determination.
> >
> > -Ekr
> >
> >     So in answer to
> >
> >     > QUESTION3: To authors and those who preferred updating RFC 7221
> with clarified text, would this be an acceptable alternative?
> >
> >     Yes, as part of a wider initiative, because it isn't just this RFC.
> And I'd point at the EMO Directorate as the responsible body. If they won't
> >     > Firstly, there was rough consensus in the room that, as it stands
> now, the working group procedures in the IETF are not clearly described.
> This ambiguity is reflected in RFC 7221. It is hard to find information
> about the practical ways of working in IETF wgs, which is a problem
> especially for getting new people actively involved.
> >     > The authors of draft-carpenter-gendispatch-rfc7221bis have written
> an update to RFC 7221 (that would obsolete it) with the intent to clarify
> the existing information. If this document (7221bis) was to move forward, I
> >     > I want to note that this is a much bigger conversation than the
> draft that we are trying to dispatch, but we can't really recommend one
> outcome for this particular document without considering the bigger
> picture. As a result, my first recommendation would be to set up a mailing
> list to have a venue to continue this discussion on the content of 7221bis
> - clarifying IETF ways of working.
> >     >
> >     > Possible dispatching outcomes (in no particular order) that are,
> in my opinion, the most likely outcomes based on the discussion are
> described below. I added some questions, which are of course conditional on
> the outcome.
> >     >
> >     >             QUESTION1: afaict this was not addressed during the
> meeting - does anybody feel like a wg should be created for this? (as
> opposed to AD sponsored, and advertised on the lists above)
> >     >
> >     >             QUESTION2: I want to re-iterate the question to those
> who objected to this outcome - knowing that there is already a note in the
> >     > 2) Do not publish this draft, but rather treat the text like the
> Tao, publish it on the website (for ex ietf.org <http://ietf.org> "how we
> work").
> >     >
> >     >       - the text still needs review. The newly created list could
> be used, plus updates could be made on the wg-chairs and ietf@ietf lists.
> >     >
> >     >             * During the meeting the question came up if the IESG
> could mark RFC 7221 as historic (if we can do that for informational),
> possibly linking from the datatracker to the website. We could follow the
> example of RFC 6722 for the Tao, and obsolete RFC 7221 with such a
> document, while pointing to the webpage.
> >     >             QUESTION3: To authors and those who preferred updating
> RFC 7221 with clarified text, would this be an acceptable alternative?
> >     >
> >     > Additionally (and out of scope of our dispatching discussion) I
> wanted to note that it was brought up that there might be need to revise
> RFC 2418. This could be the BCP which was mentioned above.
> >     > ---
> >     >
> >     > Thanks,
> >     > Francesca
> >     >
> >
> >     --
> >     Gendispatch mailing list

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 17:20:58 -0500

Francesca Palombini <[email-masked]> wrote:
    > raised, stating that too often informational RFCs are taken as
    > rules. There was strong voices in the room in both directions about if
    > any text would be helpful to clarify that this is a purely descriptive
    > document, not to be taken as guidelines or rules.

I want to say that multiple people during the meeting were surprised that the
"2-week WG Adoption call" was not, in fact, a rule.
That is, ignorance of 7221 is rampant, and new participants, including many
chairs, are simply unaware that there are options.

Further, Bron brought up the view that he looks for a specific rule to follow
*IN ORDER* that his actions are not easily subject to appeal.

As such, I think that we need a strong clarification of what is a rule, and
what is not in fact, a rule.

I think that process RFCs are regularly ignored regardless of their status.
As 7221bis tries to clarify what are rules and what are not, it's entirely
okay if it it's view of what are rules are in fact, perceived as rules.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide