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

From: Jen Linkova <[email-masked]>
Date: Tue, 7 Jul 2020 20:33:46 +1000

On Sat, Jun 27, 2020 at 9:36 AM Bob Hinden <[email-masked]> wrote:
> This message starts a two week 6MAN call on adopting:
>
>  Title:          Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events
>  Authors:        F. Gont, J. Zorz, R. Patterson
>  File Name:      draft-gont-6man-slaac-renum-08
>  Document date:  2020-05-18>
>  https://tools.ietf.org/html/draft-gont-6man-slaac-renum
>
> as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on 10 July 2020.

First of all I agree that we do have a problem with flash renumbering
and it would be desirable to make the protocol more robust.
However I have some reservations about the changes proposed by the
draft and I do not support the adoption in its current form.
(I'd disagree with the argument that 'adopting does not mean the draft
will be published as it is so let's adopt it and figure out the
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.

It's not the case for this draft for me.
In particular,
- the draft proposes some fundamental changes to the SLAAC. The full
impact of those changes, especially if the network can not guarantee
all ND packets to be delivered, is unclear.
- the draft drastically increases the complexity of the SLAAC state
machine. I'm not convinced the potential benefits are worth it.
Taking into account introduced complexity and not fully estimated
negative impact, it looks like the cure might be worse than the
disease. Introducing changes of that scale to *all* hosts to fix a
corner case of broken routers/software looks like a drunkard's search
principle...
- the draft assumes that RFC8028 is widely implemented while it does
not seem to be the case.
- I also agree with Lorenzo that the draft proposed a kind of
inconsistent behaviour by applying the heuristic to PIOs only. Shall
the same approach be taken for RIOs?
And any other RA option?

> There has been a lot of discussion on this draft, the chairs have some concerns with this document being adopted, but wanted the w.g. to express its opinion.  Our concerns include:
>
> This document proposes significant changes to SLAAC to fix what could be seen as an implementation problem in some edge routers.  This will affect all IPv6 nodes, not only the ones communicating with these edge routers.  This part of IPv6 is a mature standard.   It is not clear we should modify all IPv6 hosts to deal with one corner case that may break other things allowed by the standard.
>
> The changes proposed will make SLAAC more active, the changes include:
>
>  o Reducing the default Valid Lifetime and Preferred Lifetime of PIOs

I fully support this part of the proposal. Reducing the default values
for valid and preferred lifetimes so prefix and router lifetimes are
of the same magnitude does make sense. It's what I have deployed
anyway.

>  o Caps the received Valid Lifetime and Preferred Lifetime of PIOs.
>  o Frequent retransmission of configuration information
>  o Routers send all options in RA messages
>
> Some additional questions for the w.g. to consider:
>  o Are there better approaches to address the underlying issue?

Not sure if they are better or not, but off top of my head:
- I do not see the reason to force the invalidation of the prefix. If
the goal is to be able to communicate to 'new owners' of addresses in
that prefix, then
it would be enough to clear all on-link information when the prefix
gets deprecated.
- if we assume that hosts support RFC8028/Rule 5.5 then all the
routers need to do is to use the new Link-Local address every time the
PIOs set is changing (create a hash of PIOs or smth to generate the 64
bits of interfaceID). So as soon as the set of advertized PIOs has
changed, the router would send X new RAs from the new LLA. The hosts
would detect the old LLA being unreachable via NUD and switch to the
new prefix(es).
- we already have a mechanism for finding out what address works -
it's called Happy Eyeballs.
- I'm obviously biased here [1], but why can we not let the source
address selection to deal with it?
[1] https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00

>  o Do the proposed changes work in all deployments?

That's my main concern. In multiple RA scenario the proposed mechanism
does not seem to be resilient to packet loss

>  o Are some proposed changes worth advancing even if the entirety may not be? If so, which ones?

I'd fully support reducing the default values for the lifetimes.

-- 
SY, Jen Linkova aka Furry

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 7 Jul 2020 15:00:16 +0400

On Tue, Jun 30, 2020 at 11:25 PM Michael Richardson
<[email-masked]> wrote:
>
>
> I think that we have a rough consensus that there are events that seem to
> cause long-connecting devices (such as desktops, TVs, appliances) to
> sometimes fail to notice when there is a renumber.
> ("Short-connecting" devices like phones tend to join/leave often enough that
> they usually get recent info. and they get tested more for this)
>

There is a problem to be solved there and I support adoption of this Draft.

> It seems that for the non-flash case, that there is a lack of complete
> testing/implementation for the various cases, most of which are probably
> already dealt with given proper implementation of the protocols.
> The result is that many of us see renumbers which do not get deployed
> smoothly, and we assume a flash renumber when in some cases, it was not.
> ("Your failure to plan ahead is not an emergency to me")
>
> The result is that the urgency of this situation varies by experience, and by
> quality of implementation.  It seems that if we had an RFC that dealt with
> the **FLASH** renumbering situation, that by construction, devices that dealt
> with that would also deal smoothly with the planned renumering situation.
> (Didn't we have an entire WG at one point to renumbering? I think it didn't
> end that successfully, but that was during years I spent less time on IETF)
>
> As Erik points out, I think that there a number of active measures that can
> mitigate the situation without changes to RAs, but I also think that we can
> plan long term such that each end of the conversation is trying to make
> things go smooth.
>
> To clarify: I think we should adopt this document, provided we can more
> constructive understand that we do not all see the same part of the Elephant.
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Jul 2020 10:11:07 -0400

It might be worth thinking about how it would be different than the current behavior, when stale information is present and new, valid information is being advertised but not reliably heard. Do things get worse or better with this change?

> On Jul 7, 2020, at 06:34, Jen Linkova <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Jul 2020 15:45:29 -0300

Hello, Jen,

Some meta comments/questions:

Could you please note, explicitly, which of the specific proposals you 
are arguing against, and which you are in favor?

It would seem to me that, if anything, you're only arguing against 
Section 4.5. That's *one* out of 5 sections with proposed mitigations. 
So I'm curious why, if that's the only part you are arguing against, the 
result of your assessment would be to not support adoption of this document.

IN your email, you also argue that you are not sure the proposed 
mitigation (I assume you're referring to Section 4.5? -- but please 
specify) is robust to packet loss. Could you please sketch a sample 
scenario, such that we can confirm what you're suggesting, or otherwise 
disagree with it?

Thanks,
Fernando

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Jul 2020 16:22:47 -0300

Hello, Jen,

I've asked/commented on meta issues in my previous response to this
email. Please find below more specific comments.

On 7/7/20 07:33, Jen Linkova wrote:
>> Title:          Improving the Robustness of Stateless Address
>> Autoconfiguration (SLAAC) to Flash Renumbering Events Authors:
>> F. Gont, J. Zorz, R. Patterson File Name:
>> draft-gont-6man-slaac-renum-08 Document date:  2020-05-18> 
>> as a working group item. Substantive comments and statements of
>> support for adopting this document should be directed to the
>> mailing list.  Editorial suggestions can be sent to the authors.
>> This adoption call will end on 10 July 2020.
> 
> First of all I agree that we do have a problem with flash
> renumbering and it would be desirable to make the protocol more
> robust. However I have some reservations about the changes proposed
> by the draft and I do not support the adoption in its current form.

Could you please spell which changes you are arguing against, which ones
you are in favor, and which ones you are, say, agnostic with?

> (I'd disagree with the argument that 'adopting does not mean the
> draft will be published as it is so let's adopt it and figure out
> the 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.

My understanding is that adoption means that there's agreement on the
problem to be solved, and that the document serves as a basis for the WG
to work on the issue. Clearly, a document that is still an individual
submission does not necessarily reflect WG consensus -- even when we
have worked with folks that have submitted feedback in that direction.

Maybe the AD can clarify?

> It's not the case for this draft for me. In particular, - the draft
> proposes some fundamental changes to the SLAAC.

Could you please spell what are the fundamental changes you are
referring to?

> The full impact of those changes, especially if the network can not
> guarantee all ND packets to be delivered, is unclear.

I'm not sure how to parse this statement. We did assess the changes. If
you find that the proposed changes may have some ill effect, maybe you
could suggest an scenario where that might be the case, and also
describe how the issue is so fundamental that it cannot be easily fixed
in the current document?

> machine.

Again: Which of the mitigations do you think that increases the state
machine? -- And, if you are referring to Section 4.5, is there a
substantial complexity increase with respect to RFC8028?   --- Note:
without RFC8028, IPv6 multiprefix support is essentially badly broken.

> I'm not convinced the potential benefits are worth it. Taking into
> account introduced complexity and not fully estimated negative
> impact, it looks like the cure might be worse than the disease.
> Introducing changes of that scale to *all* hosts to fix a corner case
> of broken routers/software looks like a drunkard's search 
> principle...

Robustness essentially means ability to deal with scenarios where
network elements are not behaving as expected. So the inability of SLAAC
to deal with information that becomes stale seems to me like a problem
with SLAAC itself, as opposed to "a corner case".

> - the draft assumes that RFC8028 is widely implemented while it does 

I'll repeat again: you are problably referring to one section (SEction
4.5), out of *five* sections with mitigations. Could you please clarify
that?

That aside, Section 4.5 of this draft doens't assume that RFC8028 is
deployed. However, the engineered mitigation builds on top of RFC8028 --
which is a SHOULD as per Node Reqs -- since otherwise multiprefix
support is badly broken.

> the same approach be taken for RIOs?

As noted to Lorenzo, we have focused on the problem of renumbering, for
options (PIOs) that are closely tied to the link -- unlike other
information such as RDNSS.

The WG might well consider and decide to apply similar thinking wehere
the wg thinks fit... but I'm not sure what's the relevance of that for
the decision of whether to adopt this document.

[....]
> I fully support this part of the proposal. Reducing the default
> values for valid and preferred lifetimes so prefix and router
> lifetimes are of the same magnitude does make sense. It's what I have
> deployed anyway.

Given that there are multiple mitigations being proposed, maybe it would 
be useful to spell out which ones you support, and which ones you don't?
As noted to Lorenzo, if there's *one* out of many that you object to, 
that wouldn't seem to warrant shooting down the entire document....

>> o Frequent retransmission of configuration information o Routers
>> send all options in RA messages
>> 
>> Some additional questions for the w.g. to consider: o Are there
>> better approaches to address the underlying issue?
> 
> Not sure if they are better or not, but off top of my head: - I do
> not see the reason to force the invalidation of the prefix. 

The reason is getting rid of stale information. IN a first step, that's 
unpreferring the address. IN a second step, that's invalidating the address.

> If the
> goal is to be able to communicate to 'new owners' of addresses in 
> that prefix, then it would be enough to clear all on-link information
> when the prefix gets deprecated. - if we assume that hosts support
> RFC8028/Rule 5.5 then all the routers need to do is to use the new
> Link-Local address every time the PIOs set is changing (create a hash
> of PIOs or smth to generate the 64 bits of interfaceID).

If the host figures out that information is most likely stale, isn't it 
the obvious choice to unprefer the address and subsequently (whatever 
that means) eliminate it?

That said, the change you suggest seems indeed fundamental to me, and 
only works if the local router has been modified accordingly. -- whereas 
Section 4.5 of our document tries to deal with scenarios where that's 
not the case.

> So as soon
> as the set of advertized PIOs has changed, the router would send X
> new RAs from the new LLA. The hosts would detect the old LLA being
> unreachable via NUD and switch to the new prefix(es). - we already
> have a mechanism for finding out what address works - it's called
> Happy Eyeballs.

HE is a totally different animal.

HE check whether addresses work end-to-end, including intermmediate 
systems and the destination system.

Using HE for this seems to be like blowing your head off because you 
have a headeach, instead of taking an aspirine.

And I also believe it's conceptually wrong.

> - I'm obviously biased here [1], but why can we not
> let the source address selection to deal with it? [1]
> https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00

Answer: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08#appendix-A.2

> That's my main concern. In multiple RA scenario the proposed
> mechanism does not seem to be resilient to packet loss

Could you point to the specific mitigation you're referring to, and also 
sketch an scenario where that might be the case?

Otherwise, a rather vague statement such as "does not seem to be 
resilient to packet loss" is hard to agree or disagree with, or 
acknowledge or reject.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Jul 2020 16:25:17 -0300

> It might be worth thinking about how it would be different than the current behavior, when stale information is present and new, valid information is being advertised but not reliably heard. Do thi…

We have done the associated assessment. And things do indeed get better. 
If Jen is referring to Section 4.5 (which I am assuming, since she 
didn't say), the mitigation makse sure that stale information is phased 
out *only* if there's new incoming information.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Jul 2020 09:55:35 +1200

Jen,

> the proposed standard changes in principle and is willing to work on

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.

(If you want a more abstract discussion of the topic, please see
https://tools.ietf.org/html/draft-carpenter-gendispatch-draft-adoption-00,
which should be discussed in the forthcoming gendispatch meeting,
although I won't be there because timezone.)

Regards
   Brian

---

From: [email-masked]
Date: Wed, 8 Jul 2020 10:01:46 +0200

Brian,

> or to drop it after another year of discussion.

I agree that a move of change control is what we want.
My own thoughts from observing the process:

This might be more what should happen in theory rather than what actually happens in practice.

There are several reasons for that I would imagine. One being the practice of documents having individuals named as authors.

I have tried to move the needle on change control somewhat with the use of SCM and github, but so far it's too early to tell if that makes a difference.

It's also very hard to un-adopt a document when it's first been adopted.
Given that, it is no surprise that the barrier to adoption is high and potentionally increasing over time.

Cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Jul 2020 14:01:22 +0200 (CEST)

On Fri, 26 Jun 2020, Bob Hinden wrote:

> We would like the w.g. to consider and comment on these issues when 
> responding to this adoption call.

I agree that there are problems to be solved in this space (thus I support 
adoption), but I think that the current version of the draft is way too 
overengineered and "heavy handed". I think we can achieve all the benefit 
without changing so much of current behavior.

For new communication, hosts will primarily use the GUA address with the 
highest preferred value. So this is where we should focus the effort. 
Having addresses based on valid-lifetimes around that are no longer 
functional but are not used is of very little real life problem in my 
experience. It's mostly a cosmetic problem.

In the topology of:

RGW <-> L2-switch <-> host

We can easily get RGW changes without link-down to the host. This is the 
same for wifi case if there are separate APs from the RGW. So there are 
problems that can occur without host L1 down as a signal that something 
changed.

If the RGW is power cycled and comes up with lower timers (perhaps because 
new ISP or old ISP changed DHCPv6-PD timers) we might now be in a case 
where the old PIO based addresses might have higher preferred value than 
the new RA/PIO that the RGW is now sending. So there is a problem to solve 
here.

However, I do not agree with all the valid-lifetime changes and arbitrary 
cap:ing (where did the value "48 *" come from?). I see no major upside in 
restricting network manager choice when it comes to valid times.

So perhaps we can come up with / keep some simple heuristics regarding 
lack of old PIO information and then at that point, we cap those addresses 
preferred values to be less than the currently seen PIO by the same 
router, or if there is another router announcing RAs. There might be a MAY 
section talking about connection checker kicking off for some of these 
cases to verify connectivity of those potentially no longer working 
addresses? I don't want to go too deep into solution space.

Just to iterate, I support adoption but I think the draft will need quite 
a lot of changes before I would support publication.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 12 Jul 2020 13:59:54 +0900

> 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.

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.

IMO the problem with the IPv6 only flag document was that instead of
correctly judging at the beginning that there was not enough consensus on
the basic approach of the document, the working group adopted it even
though many people had substantial reservations about fundamental
properties such a security, compatibility, and semantics. Those fundamental
objections never really went away, and in the end they resulted in the very
expensive failure mode of causing the document not to advance even though
the working group at spent a large amount of time on it.

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.

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.

We can always put the more controversial changes into a separate document
which then can be debated separately.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jul 2020 09:25:23 +1200

Lorenzo,

> 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 that's the flaw in your argument. "We" (if you mean the WG) can't remove anything from the document without adopting it, because that's how the WG gets change control.

Regards
   Brian

On 12-Jul-20 16:59, Lorenzo Colitti wrote:
> 
> 
> On Wed, 8 Jul 2020, 07:11 Brian E Carpenter, <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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.
> 
> 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.
> 
> IMO the problem with the IPv6 only flag document was that instead of correctly judging at the beginning that there was not enough consensus on the basic approach of the document, the working group adopted it even though many people had substantial reservations about fundamental properties such a security, compatibility, and semantics. Those fundamental objections never really went away, and in the end they resulted in the very expensive failure mode of causing the document not to advance even though the working group at spent a large amount of time on it.
> 
> 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.
> 
> 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.
> 
> We can always put the more controversial changes into a separate document which then can be debated separately.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 12 Jul 2020 17:32:42 -0400

Brian, what you say is technically true, but misses an important nuance.

It is perfectly possible for a WG to condition adoption on resolution of 
a problem.  Where resolution can be "remove X" or 'describe Y 
adequately", or any number of other things.  While the WG does not 
control the document, it does control the adoption process, and it 
controls what content it adopts.

Yours,
Joel

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 12 Jul 2020 21:36:29 +0000

Joel took the words out of my mouth. As in, "Fernando, you remove section xyz, we might consider adoption."

Bert

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Sunday, July 12, 2020 17:33
To: Brian E Carpenter <[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: [EXTERNAL] Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.
Brian, what you say is technically true, but misses an important nuance.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jul 2020 10:37:20 +1200

> controls what content it adopts.

Yes, certainly the WG can adopt a draft and change it simultaneously with
the adoption. So you can't argue that adoption is impossible because the
WG doesn't like the solution, if there's agreement about the problem.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 12 Jul 2020 19:12:29 -0400

That is a really odd construction Brian.  If the authors are not willing 
to make the change, then if the document is to be adopted with a change 
the working group is asking for, the WG will have to find a new set of 
editors.  While again technically allowed, it is not what authors 
usually mean when they ask a working group to adopt their document.

Put differently, if there is WG consensus that the change should be 
made, and should be made before the WG is prepared to adopt the 
document, then that is what should happen, and requesting that is 
compliant with IETF rules.

If the authors don't like that, they can say no.  And the chairs can 
either let the document drop or look for other editors to do what the WG 
wants.  Just as they can after adoption.  And the authors can look for 
another path for their document, as they always can.

But focusing on the fact that technically the document is not yet in the 
WGs hands seems to miss the point of the process.  Which is for the IETF 
to end up with a document the IETF supports.  So I find your arguments 
confusing.

Yours,
Joel

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Jul 2020 20:47:37 -0400

> 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.

    > 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.

    > 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.

    > 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.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Jul 2020 20:51:13 -0400

Joel M. Halpern <[email-masked]> wrote:
    > That is a really odd construction Brian.  If the authors are not willing to
    > make the change, then if the document is to be adopted with a change the
    > working group is asking for, the WG will have to find a new set of
    > editors.

I'm okay with this.
We don't add consensus building authors/editors often enough.

    > While again technically allowed, it is not what authors usually mean when
    > they ask a working group to adopt their document.

    > But focusing on the fact that technically the document is not yet in the WGs
    > hands seems to miss the point of the process.  Which is for the IETF to end
    > up with a document the IETF supports.  So I find your arguments confusing.

We adopt documents so that we can put them on the agenda.  That's all.

Over 15+ years, we have confused adoption with WGLC.  It has to stop.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 12 Jul 2020 22:25:43 -0400

On one level, the meaning of adoption is not clearly written down. 
therefore I can not claim you are wrong.
However, in my experience in many roles at the IETF, your description 
("We adopt documents soe we can put them on the agenda") is not what I 
have seen or done.

We often put individual documents on the agenda.

As I understand it, we adopt documents in a WG when
1) The WG wants to work on the problem; and
2) The WG agrees that the given document is a good starting point for 
the work.

No, it is not the same as WG last call.  There is no goal that the 
document be perfect.  But it is has to be good enough.  As I explained 
to some folks in one WG, if the document does not have enough clarity 
that I understand what the direction is, then no, I do not see how the 
WG can adopt it.  (The authors added the needed clarity.  I believe the 
document will be adopted.)

A working group is not obliged to accept any old text, whether it agrees 
with it or not, as a WG adopted document.

Yours,
Joel

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 13 Jul 2020 12:52:38 +0900

> we not first gone through the hundreds of emails.

Actually I don't think so. I think the problem we faced is that once a
document is adopted it becomes a WG document and the sunk cost fallacy
prompts participants to continue to work on it. If instead we had decided
that there was not enough consensus to adopt the IPv6-only flag, then the
authors could have looked for other solutions. As it happened the solution
that ended up being more successful wasn't even in this WG, it was in dhc.

The problem with your approach is that basically you are creating an
> informal

Why do you say that? We're conducting this discussion on the WG mailing
list, are we not?

> So, you are in favour of adoption.

I think you are confusing lack of objection with lack of support.
Personally, I don't think this is primarily a standards problem but an
operational one, and I don't think the problem is widespread/important
enough to work on it in 6man (whose charter is to maintain/evolve the IPv6
standards). But I could be wrong about that, and don't oppose the WG
working on the problem in 6man if that's what folks want to do. Similarly,
I don't oppose most of the document, though as I said, almost all of that
is tweaks to the defaults that could be in a v6ops BCP instead of requiring
a standards change. I do strongly oppose the idea that we need a big change
to the mechanics of SLAAC to solve this problem, and oppose the WG taking
on the document on those grounds.

---

From: Erik Kline <[email-masked]>
Date: Sun, 12 Jul 2020 21:49:58 -0700

> Maybe the AD can clarify?

Between the "first individual submission upload" and any "advance to
WGLC" is a slider with a thumb [1] for "wg adoption" somewhere along
the track.  Whether that thumb is closer to first upload or closer to
WGLC seems to vary by working group and by topic/document.

If part of a document has broad consensus and part does not, there are
still several ways forward -- many of which seem to have been
mentioned elsewhere in this thread.

[1] https://material.io/components/sliders#continuous-slider

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jul 2020 17:44:58 +1200

FYI (not for discussion here, really):

There's https://tools.ietf.org/html/draft-carpenter-gendispatch-draft-adoption
which I hope one of my co-authors will bring up in the gendispatch meeting.

Regards
   Brian

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Jul 2020 14:40:57 +0200

>    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.  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.  We can always put the more controversial
>    changes into a separate document which then can be debated
>    separately.

In my opinion, Section 4.5 is that part that actually solves the problem, 
i.e. how can a host handle a flash renumbering situation.

I do not object moving the changes to valid and preferred times to a 
separate document, however, that doesn't deal with problem that this document
tries to solve.

My recollection of the IPv6-only flag is that it failed in sunset4 and then
failed here as well. Note that during the IPv6-only flag discussion it was
proposed that DHCPv4 was used to signal lack of IPv4, which was reject by the 
authors. It is not a surprise that a solution that involves DHCPv4 met a lot
less resistance, however the IPv6-only DHCP option does not solve what the
authors of the IPv6-only flag tried to do.

If we only a adopt a document when it has rough consensus, then why adopt a
document at all, and not go to WGLC directly?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 13:30:33 -0300

On 13/7/20 09:40, Philip Homburg wrote:
[...]
> document at all, and not go to WGLC directly?

It is often the case that folks get involved in the discussions when 
such discussions involve a wg document, and when it's clear that the WG 
will otherwise ship a document.

I this particular case, I don't object to separating Section 4.5 into a 
different document (as this part and the rest of the document might make 
progress at a different pace). However, given that Section 4.5 is an 
important bit to solve the problem, and that even those objecting have 
some idea on how to tweak or replace Section 4.5, it would seem to me 
that the contents in Section 4.5  warrant adoption (whether in the same 
or in a separate document), such that the WG works and comes up with 
what the WG things it's the best way to infer, unprefer, and eventually 
discard stale information.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 13:43:35 -0300

On 13/7/20 00:52, Lorenzo Colitti wrote:
> On Mon, Jul 13, 2020 at 9:47 AM Michael Richardson 
> <mcr+ietf@sandelman..ca <mailto:[email-masked]>> wrote:
[...]
> prompts participants to continue to work on it. If instead we had 
> decided that there was not enough consensus to adopt the IPv6-only flag, 
> then the authors could have looked for other solutions. As it happened 
> the solution that ended up being more successful wasn't even in this WG, 
> it was in dhc.

Participants spend a quite different amount on energy on individual 
documents vs on wg documents (or documents that would otherwise clearly 
become wg documents).

As such, it is no surprise that when the ipv6-only flag I-D became a wg 
document, more people looked into it, and some felt that the document 
wasn't in shape to ship or continue progress.

Similarly, most of the folks who have had objections to Section to 4.5, 
had not argued against Section 4.5, and have also noted how they think 
Section 4.5 should be tweaked or replaced (you, for one, made one of 
such suggestions).

It would seem to me that adoption of a document is indeed about the 
deciding to actively work on a document, and, in the case of Section 
4.5, such work is what's needed to replace or tweak Section 4.5 such 
that the WG is happy with it.

I think it is hard to make any sort of progress on anything if folks are 
simply essentially going to object against text upon WG call for 
adoption without much detail, and without hints or guidance regarding 
how their objections can be addressed.

My understanding is that wg adoption implies the desire of the wg to 
actively work on a document, such that objections that can be addresses 
are addresses, and otherwise text that cannot be improved for the wg to 
have consensus is stripped out or moved into a separate document.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 14:31:18 -0300

Hello, Joel (and all),

To make this point crystal clear:

* We authors are willing to make whatever changes are needed for the wg 
to have wg consensus on the document (that's, in our minds, implied by 
our will of having the wg adopt the document). Such possible changes 
include tweaking the document, move portions/sections of text into a 
separate document, or removing text.

That said:

* We authors would appreciate that whatever objections are raised, their 
are clearly spelled out and, when if/possible, suggestions are made 
regarding how they could possibly be addressed (if possible).

* Vague statements such as "[i think] the proposed mechanism is not 
robust" are virtually impossible to prove, reject, or address -- and 
while I guess they might serve as an objection, they don't help much in 
addressing possible flaws (if any) or improving the document.

* I believe that the way the wg call for adoption has been issued hasn't 
helped in the first place, not only because it seems to be clearly 
biased (and I believe a wg call for adoption should be neutral, not 
biased), but also because the very call for adoption make claims about 
this document that re inaccurate and/or misleading (e.g., "the changes 
proposed will make SLAAC more active", "this is a corner case", "this 
document proposes significant changes to SLAAC", etc.). -- for instance, 
none of such claims have been backed, even when I asked/objected to them 
(https://mailarchive.ietf.org/arch/msg/ipv6/XfUtieXhAACPj92noFPD8XjuF-Q/).

Thanks,
Fernando

On 12/7/20 20:12, Joel M. Halpern wrote:
>>>>> document, a lot of the objections would go away...
>>>>
>>>> And that's the flaw in your argument. "We" (if you mean the WG) 
>>>> can't remove anything from the document without adopting it, because 
>>>> that's how the WG gets change control.
>>>>
>>>> Regards
>>>>      Brian
>>>>
>>>>> On Wed, 8 Jul 2020, 07:11 Brian E Carpenter, 
>>>>> <[email-masked] <mailto:[email-masked]>> 
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> IMO the problem with the IPv6 only flag document was that instead 
>>>>> of correctly judging at the beginning that there was not enough 
>>>>> consensus on the basic approach of the document, the working group 
>>>>> adopted it even though many people had substantial reservations 
>>>>> about fundamental properties such a security, compatibility, and 
>>>>> semantics. Those fundamental objections never really went away, and 
>>>>> in the end they resulted in the very expensive failure mode of 
>>>>> causing the document not to advance even though the working group 
>>>>> at spent a large amount of time on it.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> We can always put the more controversial changes into a separate 
>>>>> document which then can be debated separately.
>>>>>
>>>>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 14:46:23 -0300

> Joel took the words out of my mouth. As in, "Fernando, you remove section xyz, we might consider adoption."

It seems to me that what Joel said is different: the outcome of a wg 
call for adoption may be that if there parts that have support, and 
parts that don't, a document may be adopted on the condition that the 
parts that do not have support be removed before the draft-ietf version 
of the document is posted.

That's quite different from "strip this, and try again", which might not 
be the best use of the wg's energy.

Thanks,

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2020 13:56:00 -0400

And I not only do I not speak for the chairs, I do not gave a clue what the WG rough consensus is.  Yours,JoelSent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Fernando Gont <[email-masked]> Date: 7/13/20  13:46  (GMT-05:00) To: "Manfredi (US), Albert E" <[email-masked]>, "Joel M. Halpern" <[email-masked]> Cc: IPv6 List <[email-masked]> Subject: Re: [EXTERNAL] Re: Adoption Call for "Improving the Robustness of
  Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events" On 12/7/20 18:36, Manfredi (US), Albert E wrote:> Joel took the words out of my mouth. As in, "Fernando, you remove section xyz, we might consider adoption."It seems to me that what Joel said is different: the outcome of a wg call for adoption may be that if there parts that have support, and parts that don't, a document may be adopted on the condition that the parts that do not have support be removed before the draft-ietf version of the document is posted.That's quite different from "strip this, and try again", which might not be the best use of the wg's energy.Thanks,-- Fernando GontSI6 Networkse-mail: [email-masked] Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Bob Hinden <[email-masked]>
Date: Mon, 13 Jul 2020 10:59:57 -0700

This concludes the adoption call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events”

The chairs reading of results of the adoption call is that there is agreement that 6MAN w.g. should work on this problem, but there is not support for the solutions proposed in the document.

We found that Mikael Abrahamsson email captured this well:

  https://mailarchive.ietf.org/arch/msg/ipv6/01JrxBGiMmsKuB1bkks5NIgLxSQ

 "I agree that there are problems to be solved in this space (thus I support
  adoption), but I think that the current version of the draft is way too
  overengineered and "heavy handed". I think we can achieve all the benefit
  without changing so much of current behavior.”

The authors are instructed to remove the contents from Section 4 (the section headers can stay but the contents should be replaced with “TBD”) and submit a new draft named <draft-ietf-6man-slaac-renum-00> with these changes.  We will approve that as a w.g. document.

Work can then proceed to define the appropriate set of solutions, these can be added into later versions of the draft.  We urge the authors to work with the people who provided feedback to develop new text that we can build a consensus around.  Forming a design team would be a good way to proceed.

Bob & Ole

> On Jun 26, 2020, at 4:35 PM, Bob Hinden <[email-masked]> wrote:
> 
> Document date:  2020-05-18
> 
> We would like the w.g. to consider and comment on these issues when responding to this adoption call.
> 
> Bob & Ole
> 6man co-chairs

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 15:22:28 -0300

Hello, Bob,

> The authors are instructed to remove the contents from Section 4 (the section headers can stay but the contents should be replaced with “TBD”) and submit a new draft named <draft-ietf-6man-slaac-re…

Just double-checking: Are you suggesting that we remove Section 4.5 or 
that we remove the contents of the entire Section 4?

There have been objections against Section 4.5, but I haven't seen any 
to the proposals in Section 4. In fact, even explicit support for some 
of such sections have been voice (Lorenzo for Section 4.2, Jen for 
Section 4.1.1, etc.).

Thanks,

---

From: Bob Hinden <[email-masked]>
Date: Mon, 13 Jul 2020 11:46:43 -0700

Fernando,

> On Jul 13, 2020, at 11:22 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Bob,
> 
> Just double-checking: Are you suggesting that we remove Section 4.5 or that we remove the contents of the entire Section 4?

Section 4.

> 
> There have been objections against Section 4.5, but I haven't seen any to the proposals in Section 4. In fact, even explicit support for some of such sections have been voice (Lorenzo for Section 4.2, Jen for Section 4.1.1, etc.).

We would like to see each discussed separately.  Some should be easy to add back in, others, like 4.5 will be harder.

Bob

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jul 2020 14:59:51 -0400

> We would like to see each discussed separately.  Some should be easy to add back in, others, like 4.5 will be harder.

This is a confusing statement. Who is the “we” here?

---

From: Bob Hinden <[email-masked]>
Date: Mon, 13 Jul 2020 12:18:25 -0700

> On Jul 13, 2020, at 11:59 AM, Ted Lemon <[email-masked]> wrote:
> 

We as in the w.g. chairs.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 16:05:48 -0300

> We would like to see each discussed separately.  Some should be easy to add back in, others, like 4.5 will be harder.

Ok. We will proceeded as you, the chairs, have advised.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jul 2020 15:45:39 -0300

Hi, Jen,

Ping?

On 7/7/20 15:45, Fernando Gont wrote:
>>> Autoconfiguration (SLAAC) to Flash Renumbering Events
>>> support for adopting this document should be directed to the mailing 
>>> list.  Editorial suggestions can be sent to the authors.  This 
>>> adoption call will end on 10 July 2020.
>>
>>> There has been a lot of discussion on this draft, the chairs have 
>>> some concerns with this document being adopted, but wanted the w.g. 
>>> to express its opinion.  Our concerns include:
>>>
>>> This document proposes significant changes to SLAAC to fix what could 
>>> be seen as an implementation problem in some edge routers.  This will 
>>> affect all IPv6 nodes, not only the ones communicating with these 
>>> edge routers.  This part of IPv6 is a mature standard.   It is not 
>>> clear we should modify all IPv6 hosts to deal with one corner case 
>>> that may break other things allowed by the standard.
>>>
>> [1]