Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

[Ted Lemon <[e-mail]>]

The change was not inserted into the document in February of 2016.  Be that
as it may, my point is that this particular aspect of the discussion is out
of scope: if there was a process failure, appeal is your option.   I agree
that it's not a practical option.

So, independent of that, if you think that the current documented consensus
is a *problem, *then you are absolutely right to want to do a new document.
  If that's what you want, you need to do (at least) two things:

1. Explain, in a way that actually makes sense, what it is that the
document says that is wrong, and why it is wrong.   You haven't done that.

2. Explain what it should say instead.   I would argue that your
explanation either has to say "privacy isn't that important after all" or
else address the privacy issue in a way that is equally satisfactory.  I
don't see any way to do that with IA_NA.   IA_NA by definition puts the
whole privacy thing off on the DHCP server, which may or may not do the
right thing.   The client has no agency.   Using IA_PD or prefix delegation
are both clearly superior solutions to the problem.


On Tue, Jul 18, 2017 at 3:14 PM, Nick Hilliard <[e-mail]> wrote:

> Ted Lemon wrote:
> > Nick, it's not actually up to you to determine consensus, and you do not
> > seem to actually be describing a situation where there was a lack of
> > consensus.   If you feel that there was indeed an error made by the
> > chairs, who /were/ responsible for calling consensus, the right thing to
> > do would be to appeal to the chairs, and if you are not satisfied by
> > their response, to appeal to the IESG, and so on.
>
> I'm not attempting to determine consensus, simply expressing an opinion
> that there was substantial opposition to the principals behind a
> sentence that was inserted into the draft, i.e. querying whether that
> consensus existed to start with.  There isn't a problem with querying a
> decision.
>
> The difficulty with formally appealing the consensus call is that the
> change was inserted into the document in Feb 2016, and there were
> several more revisions of the document before it was published as a BCP
> some months later, and there were no objections because it wasn't
> obvious what it meant at the time.
>
> As an aside, the fact that there is a good deal of disagreement on its
> interpretation today makes it clear that that this sentence is open to
> vastly different interpretations.
>
> So procedurally, there was not a problem with the consensus process
> which means that an appeal to the chairs / IESG / etc would be almost
> certain to fail, not least because this happened some time ago.  The
> only obvious way to deal with the problem is to bring it back to the
> working group with an explicit statement of the semantic problem, which
> is what has happened.
>
> It would be useful for the chairs to express an opinion if a different
> approach were more appropriate.
>
> Nick
>
>