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

[Fernando Gont <[e-mail]>]

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:
> 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
> 
> On 7/12/2020 6:37 PM, Brian E Carpenter wrote:
>> On 13-Jul-20 09:32, Joel M. Halpern wrote:
>>> 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.
>>
>> 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
>>
>>>
>>> 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, 
>>>>> <[e-mail] <mailto:[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.
>>>>>
>>>>> 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
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


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