Subject: WGLC results: EDNS0

From: Robert Elz <[email-masked]>
Date: Sat, 02 Jan 1999 23:14:05 +1100

The working group last call period on EDNS0 has now ended.

I believe that we need a new draft, after which a new WG last call (though
a shorter one than this has been) will be held.

Aside from addressing the (mostly) editorial concerns of Peter Koch and
Thomas Narten, the draft needs an IANA Considerations section.

I can see no current consensus (and very few opinions even) on the requirements
for the IANA to register new values, so for now I will leave that for the 
author to decide and document.

The WG is, of course, welcome to provide them with some additional guidance
over what has been provided already.   Lacking any clear guidance before the
draft is published, we will then take the draft as the default requirement,
and unless there is a clear consensus that it be changed after it has appeared,
we will accept whatever the draft says.

kre

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 3 Jan 99 19:51:47 JST

Kre;

>   | The lack of discussion, which is the problem, means the WG is
>   | actually not interested to advance the draft.
> 
> It might.   It might also mean that many consider the draft to be basically
> done, and not worthy of much extra effort.

Then, all you, as a WG co-chair, need to do is to tell WG members
the draft can not advance without consensus on IANA consideration
section.

>   | But, it means that it's time to disband the WG.
> 
> No.   It might, sometimes, but is certainly not conclusive.   This WG
> has had extended discussions on some issues - it just seems that (right now
> anyway), what the method should be by which new OPT RR option codes are
> to be listed by the IANA is not of a very high priority with the group.

If you think the WG consensus is that IANA consideration section is
not essential, tell so to IESG.

> If most of the group are willing to settle for the editor's choice there,
> that is also rough consensus.

If, instead, the section is essential, it needs essential consensus.

> Before continuing this argument, I would suggest that we wait and see
> what it selected - you never know, it might be the option that you prefer...

If I were the editor, I would have made no selection of my own.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Sun, 03 Jan 1999 22:15:27 +1100

Date:        Sun, 3 Jan 99 19:51:47 JST
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | Then, all you, as a WG co-chair, need to do is to tell WG members
  | the draft can not advance without consensus on IANA consideration
  | section.

I think that is clear, but is you really feel that the WG need to be
told, then consider this that telling.

  | If you think the WG consensus is that IANA consideration section is
  | not essential, tell so to IESG.

No, I don't, and in any case, that would do no good, and nor should it
(in this case anyway).

  | If, instead, the section is essential, it needs essential consensus.

I don't know what "essential consensus" is, it needs rough consensus, just
like anything else the working group produces.

  | If I were the editor, I would have made no selection of my own.

That's also an option.   If the editor cannot decide what to say, I'm
sure he is able to tell us that, in which case we will need to decide
what should be said and tell that to the editor.   That will almost
certainly slow down the progress of the draft.   On the other hand, if the
editor is willing to make a choice, and that choice is satisfactory to
most members of the group, then we will progress faster.

kre

---

From: Robert Elz <[email-masked]>
Date: Sun, 03 Jan 1999 21:04:35 +1100

Date:        Sun, 3 Jan 99 18:36:22 JST
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | EDNS draft is a WG draft. It is my understanding that its
  | editor is responsible to reflect WG consensus to the draft.

That is true.  However where there is no apparent consensus it is
entirely reasonable for the editor(s) to arive at a reasonable position
and then see what the position of the group might be on that choice.

  | That a chair can see no consensus means there is no consensus
  | to be reflected on the document.

The document will not actually be advanced without some form of
rough consensus emerging.   Anything can go in an internet draft for
the working group to consider.

  | The number of opinions does not matter.

It both does, and doesn't.   Sheer numbers are irrelevant, but a considerable
number supporting one position, and few opposing it amounts to rough consensus.

  | A WG, of course, can have a consensus to abandon to reach
  | technical consensus.

It can, sometimes.   Here that would be equivalent to deciding to
abandon the document.

kre

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 3 Jan 99 20:36:43 JST

Kre;

> told, then consider this that telling.

No, because you, as a WG member with a opinion, is told to counter
argue.

> No, I don't, and in any case, that would do no good, and nor should it

I agree with you that it would do no good.

> like anything else the working group produces.

I mean consensus after discussion.

> most members of the group, then we will progress faster.

That is the problem.

When the chair explicitely stated that there are conflicting
opinions, the editor should not make any choice. The chair should
discourage the editor, who is likely to be the person wanting the
progress regardless of the consensus, make a choice.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 3 Jan 99 18:36:22 JST

Kre;

> I can see no current consensus (and very few opinions even) on the
> requirements for the IANA to register new values, so for now I will leave
> that for the author to decide and document.

EDNS draft is a WG draft. It is my understanding that its editor is
responsible to reflect WG consensus to the draft.

That a chair can see no consensus means there is no consensus to be
reflected on the document.

The number of opinions does not matter.

The lack of discussion, which is the problem, means the WG is actually not
interested to advance the draft.

Can you try to have some conter argument against some of the opinions or
withdraw your opinion?

> over what has been provided already.

A WG, of course, can have a consensus to abandon to reach technical
consensus.

But, it means that it's time to disband the WG.

						Masataka Ohta

---

From: Alfred Novacek <[email-masked]>
Date: Mon, 4 Jan 1999 21:49:44 +0100

Robert Elz wrote:

>[...]   This WG
>[...]

I think the group is "tired" because it is required to make a decission
that is irrelevant to the working of the draft. After all, I think that
placing the burden on the working groups that propose new items to be
managed by IANA complicates matters: Why should IANA need to keep track
which policy to use when allocating a new code, simply because different
WGs happened to reach different decissions when other resolutions would
have worked equally well?

Anyhow, we will have to decide the one or other way in order to get the
draft advanced. But I strongly suggest to urge IESG and/or IANA to publish
an RFC that will lay down this political (not technical!) decission for all
items to be assigned by IANA.

Sincerely Yours - Alfred Novacek

------------------------------------------------------------------------
Dipl.-Ing. Alfred Novacek
Institute for Data Processing in Business Administrations,
     Economics and Social Sciences
Johannes Kepler University Linz / Austria
E-Mail: [email-masked]
        [email-masked]
WWW: http://www.idv.uni-linz.ac.at

---

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Jan 1999 06:55:31 -0500

> have worked equally well?

The reason the WGs need to be involved in setting the IANA assignment
policy is that only those folks who understand the implications of
assigning new numbers are in a position to make "good" decisions. If
the IANA just started handing out (say) new RR code points to any
random user, wouldn't it be advisable to have someone with some DNS
clue actually review the request to make sure it wasn't totally bogus?

> items to be assigned by IANA.

Please take a look at RFC 2434 (BCP 26). Writing an IANA allocation
policy does not have to be very hard to do. If you don't want to think
very much what the policy should be, yet be sure that numbers aren't
assigned badly, simply use the "IETF Consensus" or "Standards Track"
allocation policy defined in 2434. Those policies tell the IANA not to
assign any numbers unless there is an RFC. Since all RFCs are reviewed
by the IESG before they become RFCs, all DNS-related assignments will
then likely be sent to the DNSING WG for review before any assignment
is actually made.

Thomas