Subject: Re: [rfc-i] Proposed Program Description for RFC Editor evolution program

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jan 2020 14:02:22 +1300

Just to say that I have no major comments on this proposal. It seems to follow the draft-flanagan-rseme model.

I would prefer it if the description stated that the chairs must be from outside the IAB and the IESG.

I note that there isn't any text about the scope. That may be wise at the level of a program description, but I'd expect the chairs to start by stating an intended scope (and the scope definition in draft-flanagan-rseme-03 seems like a good place to start).

Regards
   Brian Carpenter

On 20-Dec-19 06:19, Ted Hardie wrote:
> The IAB is seeking feedback on the proposed program description below.   While we would prefer public discussion on this list, comments may also be sent to [email-masked] <mailto:[email-masked]>.
> 
> regards,
> 
> Ted Hardie
> for the IAB
> 
> Evolving the RFC Editor Model 
> 
> 
>       Purpose
> 
> This program is intended to foster discussion and consensus on potential changes to the RFC Editor model.  Discussion of changes to how the RFC Editor function is managed, staffed, and overseen are all within scope.  After the group has come to rough consensus, it will document its output in one or more RFCs.
> 
> 
>       Program Description
> 
> 
> During the period between IETF 105 and IETF 106, the RFC Series Editor convened a number of meetings to assess how best to conduct a community discussion and consensus process for the evolution of the RFC Editor model.  During that process, an IAB program was identified as the most appropriate vehicle for the discussion, provided it allowed for open participation and used a rough consensus model for decision making. The working methods below are intended to capture the output of those meetings.
> 
> 
> This program has no predetermined constraints on the decisions of the group.  Updates to or retention of the oversight model, management, and the roles involved in the RFC Editor function are all within scope.  Because the focus of the discussions leading up to the creation of the program were on the RFC Series Editor role, there is a presumption that the group’s discussion will start with that. 
> 
> 
>       Working Methods
> 
> 
> The program is modeled on an IETF working group and uses its mailing list to develop and validate consensus among the participants.  Participants must adhere to the IETF participation policies set out in the Note Well [Note Well <https://ietf.org/about/note-well/>].   Decisions are made using rough consensus as determined by the chairs.
> 
> 
> One or more design teams may be set up during the course of the program, but their output must be considered and validated according to the usual consensus process.  Design team output has no special standing.
> 
> 
> Participants may appeal consensus calls to the IAB[RFC7282].  
> 
> 
> In addition to chairs,  the program will have an IAB program lead.  That lead will act as a liaison between the chairs and the IAB for logistical and other formal matters. All members of the IAB, including the liaison, may also participate in the group as ordinary members.
> 
> 
>       Members
> 
> 
> This program is open to participation by anyone.
> 
> 
> 
> 
> _______________________________________________
> rfc-interest mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Jan 2020 07:58:29 -0800

Hi Brian,

Thanks for the review.

> outside the IAB and the IESG.
The current plan is to have an open call for volunteers to serve as chairs
for this program, then have community feedback for those volunteers, along
the lines that the IAB uses for appointments.  The IAB does not plan to
have any sitting member act as a chair.

> I note that there isn't any text about the scope. That may be wise at the
> level of a program description, but I'd expect the chairs to start by
> stating an intended scope (and the scope definition in
> draft-flanagan-rseme-03 seems like a good place to start).
>
>
I agree that this is one of the first task of the chairs, and I expect it
to be part of the discussion with volunteers.

best regards,

Ted Hardie

> > The IAB is seeking feedback on the proposed program description below.
> While we would prefer public discussion on this list, comments may also be
> sent to [email-masked] <mailto:[email-masked]>.
> >
> > regards,
> >
> > Ted Hardie
> > for the IAB
> >
> > This program is intended to foster discussion and consensus on potential
> changes to the RFC Editor model.  Discussion of changes to how the RFC
> Editor function is managed, staffed, and overseen are all within scope.
> After the group has come to rough consensus, it will document its output in
> one or more RFCs.
> >
> >
> >       Program Description
> >
> >
> > During the period between IETF 105 and IETF 106, the RFC Series Editor
> convened a number of meetings to assess how best to conduct a community
> discussion and consensus process for the evolution of the RFC Editor
> model.  During that process, an IAB program was identified as the most
> appropriate vehicle for the discussion, provided it allowed for open
> participation and used a rough consensus model for decision making. The
> working methods below are intended to capture the output of those meetings.
> >
> >
> > This program has no predetermined constraints on the decisions of the
> group.  Updates to or retention of the oversight model, management, and the
> roles involved in the RFC Editor function are all within scope.  Because
> the focus of the discussions leading up to the creation of the program were
> on the RFC Series Editor role, there is a presumption that the group’s
> discussion will start with that.
> >
> >
> >       Working Methods
> >
> >
> > The program is modeled on an IETF working group and uses its mailing
> list to develop and validate consensus among the participants.
> Participants must adhere to the IETF participation policies set out in the
> Note Well [Note Well <https://ietf.org/about/note-well/>].   Decisions
> are made using rough consensus as determined by the chairs.
> >
> >
> > One or more design teams may be set up during the course of the program,
> but their output must be considered and validated according to the usual
> consensus process.  Design team output has no special standing.
> >
> >
> > In addition to chairs,  the program will have an IAB program lead.  That
> lead will act as a liaison between the chairs and the IAB for logistical
> and other formal matters. All members of the IAB, including the liaison,
> may also participate in the group as ordinary members.
> >
> >
> >       Members
> >
> >

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Jan 2020 13:20:47 -0500

I have some concerns about the way the process is working with respect to
the new format.

We can in theory include SVG images. Only we can't because the spec as it
is written is for a subset of SVG that no existing tool supports. So we do
not have SVG images, we have a private spec.

Yes, I know a clique decided that they only wanted black and white images.
But I think that decision should have been made by the IETF as a whole and
in full knowledge of the consequence that it would only be possible to
include images that were created by hand or with IETF-specific tools.

I want a process in which it is clear that the IETF is the community that
defines policy of that type.

And of course then we run into all the problems caused by all the silliness
that comes from the RFC series not belonging to the IETF only it does only
it doesn't because we continue to pretend that we are multiple
organizations and one organization.
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jan 2020 07:40:39 +1300

> Yes, I know a clique decided that they only wanted black and white images.

What clique was that again?

Oh yes, I remember, it was the people who bothered to express an opinion on the open mailing list where the format was debated at great length, including the reasons for excluding greyscale and colour.

I have some code for a heuristic to convert greyscale and colour to pure b&w if you want it, although I was hoping it would be added as an option to the normal tool. That said, SVG is a horrible mess when you dig into it and the tools that create it are inconsistent. This topic does need more work but b&w seems to be the least of our problems.

Regards
   Brian

On 15-Jan-20 07:20, Phillip Hallam-Baker wrote:
> I have some concerns about the way the process is working with respect to the new format.
> 
> We can in theory include SVG images. Only we can't because the spec as it is written is for a subset of SVG that no existing tool supports. So we do not have SVG images, we have a private spec.
> 
> Yes, I know a clique decided that they only wanted black and white images. But I think that decision should have been made by the IETF as a whole and in full knowledge of the consequence that it would only be possible to include images that were created by hand or with IETF-specific tools.
> 
> I want a process in which it is clear that the IETF is the community that defines policy of that type.
> 
> 
> And of course then we run into all the problems caused by all the silliness that comes from the RFC series not belonging to the IETF only it does only it doesn't because we continue to pretend that we are multiple organizations and one organization.
> 
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 15 Jan 2020 13:04:00 -0600

> Oh yes, I remember, it was the people who bothered to express an opinion on the open mailing list where the format was debated at great length, including the reasons for excluding greyscale and col…

Also, fwiw: 
<https://mailarchive.ietf.org/arch/msg/rfc-interest/P2DZFUOMrn55zAGaFczcAHHcsLs>, 
so it's a stretch to say the IETF as a whole wasn't made part of the 
decision making process.

I understand you're suggesting a different process (and fundamental 
change to what we think the RFC Editor and RFC Series are) be used in 
the future. But I have to disagree with your characterization of what 
has happened so far.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Jan 2020 15:19:57 -0500

On Wed, Jan 15, 2020 at 1:40 PM Brian E Carpenter <
[email-masked]> wrote:

> Oh yes, I remember, it was the people who bothered to express an opinion
> on the open mailing list where the format was debated at great length,
> including the reasons for excluding greyscale and colour.
>
> I have some code for a heuristic to convert greyscale and colour to pure
> b&w if you want it, although I was hoping it would be added as an option to
> the normal tool. That said, SVG is a horrible mess when you dig into it and
> the tools that create it are inconsistent. This topic does need more work
> but b&w seems to be the least of our problems.
>

SVG seems to have been deployed in the Web browsers with a high degree of
consistency.

Tiny SVG is already a profile. And the IETF has a profile on a profile
which is written in an entirely different schema language and the RFC does
not match the tool.

It is not the colour conversion that is the issue at this point, it is the
profiling that was imposed as a result of that decision.

One of the things people keep saying to me when I start talking about the
User Interface is 'we don't do that here'. Well why define a new graphics
format in that case rather than using the existing, widely supported
standard?
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest