Barry, Deliberately not replying to any one specific message... First, it seems to me that trying to rationalize the situation with registrants, change controllers, etc., is a good idea. At the same time, given that we have managed to muddle along with problems of not having clarity about responsible parties, changing contact information, and so on for 40-odd years, it is not clear to me why the problems are urgent enough to justify taking up IETF time and apparently putting it on a fast track right now. I note, for example, the immediate and future NomCom eligibility efforts as being far more important. Those considerations lead me to some sympathy with those who are suggesting this should have gone to GENDISPATCH (too late now, but maybe something from which we can learn for whatever the "next time" turns out to be) and with procedural concerns. Ordinary individual submissions usually remain in "I-D Exists" state even after there has been discussion on the IETF list and the IESG (or a relevant AD) has decided to push the discussion off to another list. For them, the information changes to identify a sponsoring AD only when the document is close to Last Call. I noticed today that this one is already in "AD is watching" state, with a sponsoring AD assigned, in the datatracker. Not a serious problem, IMO, but something that further confuses the question of whether this is your individual effort or one you are moving forward on behalf of some or all of the IESG. Putting that aside and looking at the substance of the document (including the various changes that you have queued), I'm still not sure I fully understand what problem you are trying to solve. As an example, consider one of your examples: IETF <examplewg@xxxxxxxx> Now, clearly, that puts the IETF's mark on things but so, to some degree, does "ietf.org" in the address. As far as I know, while the recommendation has gotten ever-stronger over the years, we still don't require WGs to use mailing lists based at ietf.org and, at least equally important, we sometimes consolidate mailing lists associated with concluded WGs. If one is worried about stable contact information, we could take two examples from our distant past. Had either produced IANA registries, one would not want to list the mailing list for YAM as the best contact point (in spite of that list still receiving, archiving, and distributing mail), nor would it be wise to list 822ext as either IETF <ietf-822@xxxxxxxxxxxxxxxxxx> or IETF ietf.cnri.reston.va.us:~/ietf-mail-archive/822ext/ I understand that you are talking only about new registries going forward, but the reality is that these things do change. I note particularly the suggestion about use of a "directorate or area-wide mailing list" in combination with our tendency to periodically consolidate or drop areas and invent new names in the process. Expanding the number of things that we need to keep stable for as long as IANA registries exist (and the IETF does) is probably not a good idea for just those reasons. The document actually makes that point in requiring that contact information not be published in RFCs [1]. Assuming the goal of this document is to clarify what is going on rather than simply to create consistency for its own sake and/or to create more procedural hoops for WGs, document authors, and shepherds to jump through for anything this draft considers unusual -- thereby creating more delays in document evaluation and processing -- let me suggest a simpler and less ambiguous strategy going forward: (i) For "registrant" or "contact" no change and no need to mention either in this document other than to specify that "IESG" (which is inherently transient except insofar as the changing membership makes decisions reflecting IETF consensus or on behalf of the IETF) MUST NOT appear. Even that may be a problem that does not need solving at the BCP level. (ii) For registries and registrations that really are the responsibility of the IETF for either additions or changes, require that the Change Controller field appear and that it be listed as "IETF". Not "IETF" and some mailing list, but "IETF". WGs are by definition transient so, while they might be registrants and perhaps even (for a while) contacts, they should never be listed as change controllers. Using the Applications Area and the Real Time one as very handy examples, Areas are transient too and the same considerations apply. (iii) If a WG document that specifies a registry or registration specifies, e.g., a WG Chair as registrant, it is entirely appropriate for that to be questioned by the WG, during IETF Last Call, or by the document shepherd or IESG review, but it does not seem to me we need a BCP-level document to say that. I don't think anything else is going to reduce confusion or improve contact information more than that suggestion would. It appears to me that what the proposal in the I-D would likely do is to increase the workload on both IANA and the IESG (or designees of the latter) every time we reorganize Areas, close a WG and/or decide that concluded WG mailing lists should be consolidated or moved to another location, and increase the pressure on IANA to do outreach to keep addresses up-to-date that they now correct only on an as-needed basis when things are brought to their attention. That requirement for a "Change controller" entry in registries or registrations created under IEZTF respoonsibility probably would benefit from an update to BCP 26/ RFC 8126, but I see no reason why that would be problematic. thanks, john [1] Section 2, paragraph 3 starting with "In any case...". And, btw, that statement sounds a lot like a RFC 2119-style MUST NOT unless you intend that the IESG be able to make exceptions to that too, in which case a SHOULD NOT might be appropriate. We also put "mutable email addresses into immutable RFCs" all the time: email addresses are the only contact information other than personal names that we still require in I-Ds and RFCs.
