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

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