Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25)

[Donald Eastlake <[e-mail]>]

Hi Denis,

On Wed, Jun 20, 2018 at 11:31 AM, Denis Ovsienko <[e-mail]> wrote:
> Thank you for your comments Donald, please see my questions and comments below.
>
>  ---- On Mon, 18 Jun 2018 15:27:51 +0100 Donald Eastlake <[e-mail]> wrote ----
>  > Hi Denis,
>  >
>  > Thanks for your comments.
>  >
>  > On Sun, Jun 17, 2018 at 3:21 PM, Denis Ovsienko <[e-mail]> wrote:
>  > >  > ...
>  > >
>  > > Hello all.
>  > >
>  > > I oppose the proposed change for the following reasons.
>  > >
>  > > First, the fault is not in the charter. As my previous message to the list discusses, it looks like we (the working group as a whole) have neglected some meaningful parts of our charter: "Particular emphasis will be placed on work needed for a Proposed Standard routing protocol, such as ensuring manageability and strong security." We have achieved exactly the opposite so far, and it would be fair to fix first what is actually broken (specific suggestions are in that message).
>  >
>  > This Charter change is about process and gating, not about ultimate
>  > goals. There is substantial work on manageability in the Information
>  > Model and we do have a volunteer to do a preliminary YANG model. The
>  > problem is the interlock in the current Charter between the YANG model
>  > and the base protocol getting to Proposed Standard status and the
>  > normative dependency on Babel in the HOMENT WG.
>
> I am sorry, but the only way I can read the above is it begins saying it is not about ultimate goals, and then says Proposed Standard is an ultimate goal and justifies bending the rules. Can you see it from this point of view?

No, I don't see that. There is no rule being bent. The Charter is
something specified by the IESG, the IESG can change it, and the WG
can ask the IESG to change it. Standards track status for Babel was
and remains a goal. Manageability for Babel was and remain a goal.

> The _intentional_ dependency on YANG has been in the charter for 2 years, but only now it suddenly became a "problem", do you agree it looks strange enough to deserve a proper explanation?

No, I do not agree. Perhaps everyone should always keep the WG Charter
details in mind but many IETF participants, even WG Officers,
sometimes overlook those details. And the longer it has been since the
WG was Chartered, the more memory of those details may fade although,
of course, they are still documented in writing in the Charter itself.
And the longer it has been since the WG was Chartered, the more likely
it is that circumstances have changed so that an adjustment to the
Charter is called for. So I do not think it is strange that the
"problem" is noticed now.

Let me give an example of people missing something in a Charter,
although it is a little embarrassing. When I took over as Chair of the
PPPEXT WG, Jim Carlson had long been the Chair. At the time, a draft
targeted for Proposed Standard was going through the WG, was found to
have WG consensus, and forwarded to the IESG. The only problem with
this was that the PPPEXT Charter said that the purpose of the WG was
only to review documents related to PPP and that the PPPEXT WG was
specifically prohibited from producing any new documents.  :-)
Neither Jim Carlson, who had been Chair for years, nor myself who had
taken over had noticed this. In fact, the Area Director for the WG
didn't notice this either and went ahead and issued an IETF Last Call
on the draft before this problem was noticed by another IESG member.
(The IESG solved the problem in this case by treating the document as
if it was not a WG document and re-issuing the IETF Last Call for the
required longer period of time.)

>  > > Second, de-rating of the requirements level should mean de-rating of the publication category. If the working group explicitly finds itself unable to produce a quality YANG deliverable in time, it could _potentially_ (if the charter allowed it) capture its core (6126bis + whatever security) deliverables as IETF Experimental publications, take a break and retain the motivation to have YANG eventually done and aim for Proposed Standard. But neither the current charter nor the proposed change take this into account.
>  >
>  > The entire thrust of this WG effort is to move Babel to the Standards
>  > Track and any change from that would be a major change for which I
>  > have not seen any support except your message.
>
> Standards Track work indeed has been the IETF's expectation of this working group. This was a reasonable initial expectation based on the way the pre-IETF work was presented at the IETF. That said, if the actual in-IETF results were as good as expected, there would not be this call and this discussion in the first place, do you agree?

I do not agree. Whether results are "good" or not is a judgement call.
Whether or not there is a YANG model is a factor some people would
include in such a judgement. But there are many other factors.

> I agree the proportional de-rating would be a major change to the charter. However, just writing deliverables off with no consequences would be a major change too, and in addition to that it would be difficult to distinguish from just gaming the Standards Track process. Does one of the evils look significantly less than the other?
>
> I agree 8 people on the list have voted to support the charter change so far, and I am the only one who has objected so far. Notwithstanding the fact, I believe this working group does not yet have valid grounds to declare consensus on this call and to ask to change the charter. The matter is, your message that starts this call asks for _comments_. This is indeed a valid way to start a consensus process, and it is not a warrant to reduce it to a voting. To emphasize the difference, let me quote this:
>
> "We reject kings, presidents and voting. We believe in rough consensus and running code."
>
> One of the reasons I decided to join the IETF in 2016 was I knew what this saying is intended to mean -- long before that I had read RFC 7282 (On Consensus and Humming in the IETF). The document explains in detail why opposing a majority of _votes_ with a reasoned _objection_ in a call for _consensus_ is a normal IETF approach and it should not be questioned or dismissed. Specifically, it tells why the situation with this call is _not_ a consensus (and what could be done to try to achieve it).

You are entitled to your opinion that this Charter change is not a
good idea and that either Charter should not be changed or, if it is
changed as indicated, the based Babel draft should re-cycle at
Experimental. However, that is not the consensus of the WG.

Any objection can be written up at great length and with many reasons
as to why it is a good objection. This does not mean that one person
can just block progress by writing up their objection that way. RFC
7282 applies only to technical objections and we are discussing
process here.  I'd be willing to say that a minority or one person who
point to a significant violation of process rules can stop something
even if many are in favor of it. But there is no process rules
violation in asking the IESG to make this minor Charter change. That's
not just my opinion but we have an explicit post by our AD stating it.

> To sum my position up, the right thing to do would be either to leave the charter intact or to ask for proportional de-rating on both sides of the deal like suggested, in either case the working group should keep to the intended IETF methods of work. I am willing to address any comments regarding my input to this consensus call.

"Experimental" is not a de-rating of "Proposed Standard". They are
different things for different purposes. I do not think the WG is
going outside of "intended IETF methods of work".

I'm sorry you are not happy but I do not see a reason to revisit the
determination that the WG consensus is in favor of the Charter change.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Thank you.
>
> --
>     Denis Ovsienko