[Gendispatch] IETF 109 minutes + chair summary

[Francesca Palombini <[e-mail]>]

 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