Subject: [Gendispatch] FW: New Version Notification for draft-rsalz-2028bis-00.txt

From: "Salz, Rich" <[email-masked]>
Date: Fri, 3 Sep 2021 19:37:42 +0000

I updated RFC 2028.  I would like this to be on the agenda for the next GENDISPATCH meeting. Lars suggests we can discuss it here until then if needed.  Or you can post issues or pull requests on the GitHub repo and I'll review and publish a new draft before next meeting's cutoff.

On 9/3/21, 3:33 PM, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-rsalz-2028bis-00.txt
    has been successfully submitted by Rich Salz and posted to the
    IETF repository.

    Name:		draft-rsalz-2028bis
    Revision:	00
    Title:		Entitities Involved in the IETF Standards Process
    Document date:	2021-09-03
    Group:		Individual Submission
    Pages:		10
    URL:            https://www.ietf.org/archive/id/draft-rsalz-2028bis-00.txt 
    Status:         https://datatracker.ietf.org/doc/draft-rsalz-2028bis 
    Html:           https://www.ietf.org/archive/id/draft-rsalz-2028bis-00.html 
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-rsalz-2028bis 

    Abstract:
       This document describes the individuals and organizations involved in
       the IETF standards process as described in [IETFPROCS].  It includes
       brief descriptions of the entities involved, and the role they place
       in the standards process.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 4 Sep 2021 15:59:28 +0200

Rich,

Thanks for this draft.  I think it's good at documenting the current 
state of affairs, and 2028 desperately needs such an update.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Sep 2021 10:23:26 +1200

I agree that this needs to be done. I will definitely have some comments.

Regards
   Brian Carpenter

On 05-Sep-21 01:59, Eliot Lear wrote:
>> I updated RFC 2028.  I would like this to be on the agenda for the next GENDISPATCH meeting. Lars suggests we can discuss it here until then if 
needed.  Or you can post issues or pull requests on the GitHub repo and I'll review and publish a new draft before next meeting's cutoff.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 4 Sep 2021 23:35:52 +0100

On 03/09/2021 20:37, Salz, Rich wrote:
> I updated RFC 2028.  I would like this to be on the agenda for the
> next GENDISPATCH meeting. Lars suggests we can discuss it here until
> then if needed.  Or you can post issues or pull requests on the
> GitHub repo and I'll review and publish a new draft before next
> meeting's cutoff.

Seems like a reasonable thing to do once the RSE future stuff
concludes.

Cheers,
S.

> A new version of I-D, draft-rsalz-2028bis-00.txt has been
> successfully submitted by Rich Salz and posted to the IETF
> repository.
> 
> Name:		draft-rsalz-2028bis Revision:	00 Title:		Entitities Involved
> in the IETF Standards Process Document date:	2021-09-03 Group:
> Individual Submission Pages:		10 URL:
> https://www.ietf.org/archive/id/draft-rsalz-2028bis-00.txt Status:
> https://datatracker.ietf.org/doc/draft-rsalz-2028bis Html:
> https://www.ietf.org/archive/id/draft-rsalz-2028bis-00.html Htmlized:
> https://datatracker.ietf.org/doc/html/draft-rsalz-2028bis
> 
> 
> Abstract: This document describes the individuals and organizations
> involved in the IETF standards process as described in [IETFPROCS].
> It includes brief descriptions of the entities involved, and the role
> they place in the standards process.
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Sep 2021 11:16:10 +1200

Rich,

Thanks for starting this, it was badly neeeded.

> Abstract
> 
> This document describes the individuals and organizations involved in the IETF standards process as described in [IETFPROCS]. 

This reference should be to BCP9, not to RFC2026 which has been significantly amended. In general, citing BCP numbers is much more future-proof.

> It includes brief descriptions of the entities involved, and the role they place in the standards process.

Nit: s/place/play/

>  1. The IETF Standards Process
> 
> The process used by the IETF community for the standardization of protocols and procedures is described in [IETFPROCS]. That document defines the stages in the standardization process, the requirements for moving a document between stages, and the types of documents used during this process. 

Again, BCP9 not RFC2026. (And that only scratches the surface, as illustrated by https://www.ietf.org/standards/process/informal/ .)

> It also addresses the intellectual property rights and copyright issues associated with the standards process.

No, that's been removed to two separate documents, BCP78 and BCP79.

>  3.1. The Document Editor or Author
...
> When a Document Editor is a Chair of the same working group, a co-chair should manage the process around the document. If a co-chair is not available, the process must be monitored carefully to ensure that the resulting documents accurately reflect the consensus of the Working Group and that all processes are followed. This can be the collective obligation of all parties involved in the document.

I completely agree with this, but it belongs in RFC2418bis, not here.

>  3.2. The Working Group Chair
...
> The details on the selection and responsibilites of a Working Group chair can be found in [WGPROCS].

That reference needs to be BCP25, as RFC2418 has also been significantly amended.
 
>  3.4. The Request for Comments Editor

This section should probably just be TBD until the RFC Editor model work is concluded.

>  4.2. Working Groups
...
>  The full intellectual property policy is defined in [IPRPOLICY].

That reference should be [BCP78], [BCP79].

>  4.3. Internet Engineering Steering Group (IESG)
...
>  See [NOMCOM] for a detailed description of the Nomcom procedures. Other matters concerning its organization and operation, are described in the IESG charter [IESG]

Again, please refer to the BCPs.

>  4.4. Internet Architecture Board (IAB)
...
> described in the IAB charter [IAB]

BCP39 

>  4.5. Internet Assigned Numbers Authority (IANA)
...
>  as documented in [IANADOCS].

BCP26

> IANA also is responsible for operating and maintaining several aspects of DNS and coordination of IP address numbering

s/numbering/assignment/

I think there's a missing sentence, something like

The IETF's relationship with IANA is defined by formal agreements including [RFC2860]. 

>  4.6. IETF Secretariat 

For clarity, I suggest moving this to just after the section describing the LLC.

>  4.8. The IETF Trust
> 
> The IETF Trust holds the copyrights for IETF documents including RFCs, and copyright licenses for IETF contribtions including Internet Drafts. The principles for the copyright licenses are described in [COPYRIGHT],

...described in [BCP78] and [COPYRIGHT]

>  4.9. IETF Administration LLC (IETF LLC)...
...
> [LLCLEGAL], Section 6 describes the legal relationship between the LLC and ISOC.

True, but 'LLCLEGAL' is a very misleading handle for RFC8712. See next comment:

>  4.10. Internet Society (ISOC)
> 
> ISOC plays a small but important role in the standards process. It appoints the NomCom Chair, confirms IAB candidates, and acts as the last resort in appeals process

In my view, this sentences belittles the relationship.  I would start by reinstating some text from RFC2028, boosted by a reference to RFC8712 which goes into more detail: 

Internet standardization is an organized activity of the ISOC, with
the Board of Trustees being responsible for ratifying the procedures
and rules of the Internet standards process [RFC8712].

(We might consider that if this draft is to become an IETF process BCP, it will need to be ratified by the ISOC Board, like all our process BCPs. So we kinda have to include this text.)
 
Regards
   Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Sep 2021 17:22:15 +0000

That's an EXCELLENT point.  The target for IETFPROCS is now BCP9. So multiple changes happened in the RFC->BCP changes, and I won't call all of them out.

    Nit: s/place/play/

Done.

I removed the sentence.

    ...

I disagree, and am not making this change because I think the "this can be" sentence describes the individuals in the same way the other sentences about individuals do.  Of course, if/when  adopted, the consensus may argue against me.  So keep this mail :)

I expect it will be updated once that group is done, yes :)  If nothing else it serves as a placeholder and shows how much text to allow for the section (just kidding, sort of).

BCP10 for NOMCOM, but which one were you thinking of for the IESG?  BCP92 isn't appropriate.

>    The IETF's relationship with IANA is defined by formal agreements including [RFC2860]. 

Added that sentence and ref, thanks.

Done.

Changed it ISOCIETF

I added this and s/small but important/an important/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Sep 2021 09:52:08 +1200

> BCP10 for NOMCOM, but which one were you thinking of for the IESG?  BCP92 isn't appropriate.

You're right. I'm a bit surprised that RFC3710 is Informational, but it is. (It's also updated by three different BCP's, which is a bit odd, but there it is.)

Regards
   Brian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Sep 2021 16:27:51 -0400

-- Section 4.3 --

   The IESG is composed of the
   IETF Area Directors and the IETF Chair, who also chairs the IESG and
   is the Area Director for the General Area.

   All members of the IESG are nominated by a nominations committee
   (colloquially, NomCom), and are approved by the IAB.  See [NOMCOM]
   for a detailed description of the Nomcom procedures.

The document in general is inconsistent in how it handles this stuff.
For example, Section 4.4 says, "The IETF Chair is an ex-officio member
of the board.", but does not say that the IRTF Chair is also, and 4.3
does not mention that the IAB Chair is also an ex-officio member of
the IESG.

In 4.3 and 4.4, "and are approved by" should say, "and are confirmed
by", as that's the term that's used in the BCPs.

Sections 4.8 and 4.9 don't try to talk about how the members (of the
Trust and the LLC Board) are selected or confirmed, and simply refer
to the BCPs.  It's probably best if 4.3 and 4.4 follow that as well
(making my previous paragraph moot).

Section 4.8 should also include trademarks as something the Trust deals with.

The Internet Society seems to have consolidated its branding to the
full name and seems not to use "ISOC" these days, even to the point of
redirecting <isoc.org> to <internetsociety.org>.  Given the few
mentions that there are, we should probably use "the Internet Society"
throughout, and just not say "ISOC" at all (though I think it's fine
to use "[ISOC]" for the reference citation).

In Section 4.7 you have a typo: ISRG

In Section 4.9 you have a typo: rseponsible

-- 
Barry

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Sep 2021 13:42:48 -0700

> does not mention that the IAB Chair is also an ex-officio member of

I think Barry's message is well-reasoned and correct to the extent I
understand all of the various roles, but I wonder if corrections to Rich's
document are the best way to move forward.

By writing it all down, Rich seems to have shown that some of these
relationships are absurdly complex. I'm not saying that was the intent.
Sometimes these things only become evident after you try to document them.

Nevertheless, I support publishing the document as accurate documentation,
but I tend to view it as a problem statement.

thanks,
Rob

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Sep 2021 08:59:46 +1200

On 09-Sep-21 08:42, Rob Sayre wrote:
...
> By writing it all down, Rich seems to have shown that some of these relationships are absurdly complex. I'm not saying that was the intent. Sometimes these things only become evident after you try to document them.

They are complex as a result of history, but trying to straighten out a plate of spaghetti is generally held to be impossible. We have a plate of our own spaghetti to sort out first: https://www.ietf.org/standards/process/informal/

   Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Sep 2021 12:54:42 +0000

> By writing it all down, Rich seems to have shown that some of these relationships are absurdly complex.

I don't see it as absurdly complex, far from it. You need to separate the "control plane" (how people are picked for positions) from the "data plane" (how documents flow through to become RFC's). Perhaps the doc could be more clear about that.  What do you think is absurdly complex, ideally in the data plane part.

> We have a plate of our own spaghetti to sort out first: https://www.ietf.org/standards/process/informal/

Ideally, once this draft gets adopted and then published, that page basically goes away and points to the document.  We already have the Tao. Write things once.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Sep 2021 13:18:52 +0000

Thank you for the diligent and careful review! Changes are in https://github.com/richsalz/draft-ietf-rfc2028bis/pull/5

That's a good point.  Fixing that was fairly minor, so I decided to be complete rather than trying to focus on "the important parts" of the RFC process.

Fixed, thanks.

I think the summary that's there is worthwhile to readers. I suppose I could add how the LLC and Trust Board is picked. One argument against that is, like above, it's not something many deal with.  Thoughts?

Good catch.

Fixed.

Fxied :)

Mooted by Colin's proposal.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Sep 2021 10:23:36 -0400

Thanks for addressing my comments, Rich.  On the open question:

> I think the summary that's there is worthwhile to readers. I suppose I
> could add how the LLC and Trust Board is picked. One argument against
> that is, like above, it's not something many deal with.  Thoughts?

I'm ambivalent.  On the one hand, I like to have things specified in
one place, so we don't have to update multiple things when something
changes.  On the other, these details aren't likely to change, so I
don't see much harm in summarising them here.  So for me, I'd leave it
to your judgment how to keep the document internally consistent.

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Sep 2021 11:24:27 +1200

On 10-Sep-21 00:54, Salz, Rich wrote:
> Ideally, once this draft gets adopted and then published, that page basically goes away and points to the document.

Oh no, it doesn't. Have you ever actually contemplated how many process-related documents the IETF has? (At a rough count, 75.) It is truly impressive. The list is below my signature.

> We already have the Tao. Write things once.

The Tao nowhere near covers all you might need to know. It's the IETF for Dummies, really.

   Brian

[RFC1311]
[RFC2026]
[RFC2028]
[RFC2119]
[RFC2360]
[RFC2418]
[RFC2438]
[RFC2850]
[RFC2860]
[RFC3005]
[RFC3233]
[RFC3552]
[RFC3677]
[RFC3683]
[RFC3710]
[RFC3933]
[RFC3934]
[RFC3935]
[RFC3967]
[RFC4052]
[RFC4053]
[RFC4181]
[RFC4633]
[RFC4691]
[RFC4775]
[RFC4841]
[RFC4845]
[RFC4846]
[RFC4858]
[RFC4858]
[RFC4897]
[RFC5378]
[RFC5378]
[RFC5434]
[RFC5657]
[RFC5704]
[RFC5706]
[RFC5742]
[RFC5743]
[RFC5744]
[RFC5745]
[RFC6410]
[RFC6576]
[RFC6701]
[RFC6702]
[RFC6771]
[RFC7120]
[RFC7154]
[RFC7221]
[RFC7282]
[RFC7322]
[RFC7475]
[RFC7649]
[RFC7841]
[RFC7942]
[RFC8067]
[RFC8126]
[RFC8174]
[RFC8179]
[RFC8711]
[RFC8712]
[RFC8713]
[RFC8714]
[RFC8715]
[RFC8717]
[RFC8718]
[RFC8719]
[RFC8720]
[RFC8721]
[RFC8722]
[RFC8728]
[RFC8729]
[RFC8730]
[RFC8788]
[RFC8789]

---

From: Rob Sayre <[email-masked]>
Date: Thu, 9 Sep 2021 16:57:57 -0700

On Thu, Sep 9, 2021 at 4:24 PM Brian E Carpenter <
[email-masked]> wrote:

> Oh no, it doesn't. Have you ever actually contemplated how many
> process-related documents the IETF has? (At a rough count, 75.) It is truly
> impressive. The list is below my signature.
>

Fully agree (with the caveat that we are all dummies, present company and
myself especially).

I think Brian's message does a better job of communicating what I was
trying to say.

The document is still worth doing, and I support it.

thanks,
Rob

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Sep 2021 13:34:57 +0200

As I wrote earlier, I support this draft going forward, and I think the 
best way is AD-sponsored.

The one aspect of this that I mentioned to Rich and Lars was that I 
think we should look at whether this document should be looked at 
normatively or whether it is meant as an informational document.  That 
is– should the process of updating this document update documents other 
than obsoleting 2028?  I would very much like the answer to that 
question to be NO.

We have to be sure that we're not doing that by accident, and one way to 
do that is to make this document Informational.  Another way to do that 
is to say that explicitly we are not updating any other documents, and 
when in doubt, go to those other documents. A third way of doing that is 
to go read that long list of documents to make sure we are not creating 
ambiguities.

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 10 Sep 2021 14:10:20 +0000

Luckily I'm friends with the webmaster there :)

For a group that prefers to work on bytes on the wire, we sure do an awful lot of navel-gazing.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Sep 2021 08:26:40 +1200

> Luckily I'm friends with the webmaster there :)

You're not the only one, however.

> For a group that prefers to work on bytes on the wire, we sure do an awful lot of navel-gazing.

Sure. And the result of that is the collection of 75 RFCs that I cited. If you care to start a project to reduce that number, I think you'll find that https://xkcd.com/927 applies here too.

   Brian

---

From: Rob Sayre <[email-masked]>
Date: Fri, 10 Sep 2021 13:38:21 -0700

On Fri, Sep 10, 2021 at 1:26 PM Brian E Carpenter <
[email-masked]> wrote:

> Sure. And the result of that is the collection of 75 RFCs that I cited. If
> you care to start a project to reduce that number, I think you'll find that
> https://xkcd.com/927 applies here too.
>

Yes, I think that XKCD problem is in play. I've noticed the tension arises
from the fact that some procedures are deliberately vague (good for dealing
with someone that is being a pain), but others have been made precise due
to bad management in the presence of ambiguity (deliberate or accidental).
The management problems seem difficult, so I am not surprised the IETF
ended up with 75 drafts.

thanks,
Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 11 Sep 2021 13:02:20 +0000

I know Greg has other friends.  Probably better ones than me.  Hence the smiley :)

    > For a group that prefers to work on bytes on the wire, we sure do an awful lot of navel-gazing.

    Sure. And the result of that is the collection of 75 RFCs that I cited. If you care to start a project to reduce that number

Nope.  My primary interest for this is helping to make sure that we have documents that express the way things are now.  Everyone agreed 2028 needed to be updated. I wonder what would be next on the list?

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Sep 2021 09:41:46 +1200

> Nope.  My primary interest for this is helping to make sure that we have documents that express the way things are now.  Everyone agreed 2028 needed to be updated. I wonder what would be next on th…

Both 2026 and 2418 are pretty rusty. I suspect that a thorough update of both of those could get rid of a significant fraction of the other 73. But it would be a major effort, and might not be cost-effective.

   Brian