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

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

On 7/12/2020 5:25 PM, Brian E Carpenter wrote:
> 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, <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> 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.
>>
>> 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.
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 