Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

[Michael Richardson <[e-mail]>]

Lorenzo Colitti <lorenzo=[e-mail]> wrote:
    > On Wed, 8 Jul 2020, 07:11 Brian E Carpenter, <[e-mail]>
    > wrote:

    >> > content later'. IMHO adopting the draft means that the WG agrees with
    >> > the proposed standard changes in principle and is willing to work on
    >> > polishing the details.
    >>
    >> No, that isn't what it means. In fact it's rather undefined what
    >> "adoption" means, but the most important thing it means is that
    >> change control moves from the authors to the WG. So the WG can choose
    >> to polish the draft a bit, or to completely change the proposal,
    >> or to drop it after another year of discussion.
    >>
    >> If you remember, draft-ietf-6man-ipv6only-flag was an example of
    >> both the 2nd and 3rd possibilities.
    >>

    > Actually, what happened with the IPv6-only flag is a really good example of
    > why we should *not* adopt this document in its current form.

Hmm.
I find your entire description to be a really good example of why we should adopt.

    > The IPv6-only flag document took a huge amount of the working group's time,
    > and that time basically ended up being wasted because it did not result in
    > the publication of an RFC. If I recall correctly, the authors had to revise
    > the proposal several times, hundreds of emails were written to debate the
    > issue on both sides, and discussion flared up several times as the folks
    > who opposed the proposal continued to oppose each new version on the same
    > fundamental grounds. In the end, the working group chairs had to make a
    > tough call that there was in fact no consensus to advance the document and
    > all that work was essentially abandoned.

    > I think it's very instructive to compare that process with the advancement
    > of the IPv6-only DHCP option. That option essentially solves the same
    > problem, but started off with a lot more consensus and has already gone
    > through both working group last call and IETF last call.

I think that we could never have found the IPv6-only DHCP option solution had
we not first gone through the hundreds of emails.

I think that better decorum could have been observed, and some ideas from
manycouches about limiting number of postings/period (a token bucket) would
have helped significantly, but basically, I claim that this is positive
example.

    > I think we should avoid the risk of repeating that mistake and using large
    > amounts of the working group's time on this document. I think there are
    > parts of the document that many participants agree on, and we should keep
    > them, so the document can advance more easily.

The problem with your approach is that basically you are creating an informal
(adhoc) working group before the working group.

    > It seems pretty likely to me that if we remove section 4.5 from the
    > document, a lot of the objections would go away and we would end up with a
    > document that would be much more likely to be adopted without controversy,
    > and advance to publication quickly and without lots of disagreement.

So, to summarize:
 1) you agree that there is a problem!
 2) you like 70% of the document
 3) once adopted, you want to seek consensus of the WG to remove section 4.5.

So, you are in favour of adoption.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-