Re: Conclusion of Adoption Call for <draft-troan-6man-universal-ra-option>

[Erik Kline <[e-mail]>]

Tim,

If this is going to move forward I think there needs to be some guidance
text for defining new options; specifically, a discussion about the
semantics for protocol designers, e.g., information that must be delivered
to a single node vs information safe to deliver to all nodes (multicast vs
unicast) sort of issues.  Right now we only have options that are safe to
consume by all nodes.  While it seems reasonable to me to continue in that
vein, I think it's useful to have text reminding the designer of any new
option about these considerations.

(Also, we might want to have another look at 8801.  The PVD option can
contain an entire RA header, and I don't recall there being a URI element
(just the FQDN).)

Thanks,
-Erik

On Fri, Oct 22, 2021 at 9:27 AM Timothy Winters <[e-mail]> wrote:

> Hi Bob,
>
> Thanks for the detailed explanation of the adoption call.
>
> The authors reviewed the feedback from the adoption call and have updated
> the document.  We have removed DHCPv6 using these options as that seemed to
> trigger a great deal of concern during the adoption call.   Additionally we
> removed the options that are only represented in Router Advertisements to
> avoid the conflict issue if a host is getting information from two places.
>
> We'd like to get the working group feedback on this version of the
> document.   Overall we found there was positive interest in having an
> option for RAs that would be more flexible and faster to make available.
>
>
> https://datatracker.ietf.org/doc/html/draft-troan-6man-universal-ra-option
>
> Regards,
> Tim
>
>
> On Tue, Sep 28, 2021 at 1:34 PM Bob Hinden <[e-mail]> wrote:
>
>> The adoption call for this draft officially ended on 6 September 2021.
>> The discussion continued after that.  As of today, there were about 130
>> responses to the adoption call.
>>
>> While some of the discussion was about adopting the draft and its merits,
>> a lot was not.   It ended up moving into several general discussions of RAs
>> vs. DHCPv6 repeating discussions that have happened multiple times over the
>> years.
>>
>> My conclusion is that while there is some interest in taking this work in
>> 6MAN, based on the email discussion, this draft raises more issues that it
>> solves.   The issues raised are not ones that have straightforward
>> technical solutions and can be fixed in a revised draft, but are larger
>> architectural issues.  It is not clear there could be a path toward a
>> consensus to later advance this document given these issues (RFC 7221
>> section 2.2).
>>
>> The draft's main goal of making it possible to define new options for RAs
>> and DHCPv6 without IETF standardization, may result in more ways of doing
>> host configuration, instead of unifying it (as least for some very long
>> transition period).
>>
>> Also, worth noting that since this would be creating common options for
>> DHCPv6, this would also need discussion and agreement in the DHC working
>> group.
>>
>> My personal view is that while it is a reasonable goal to make it easier
>> to create new RA and DHCP options and reduce the debate on standardizing
>> these, the other issues this approach raises are problems that are much
>> harder for the IETF to solve given the range of views expressed on the list.
>>
>> Based on the adoption call discussion, prior to this draft being
>> reconsidered in 6MAN (and probably with DHC) it would be constructive to
>> develop a separate document specifying what kinds of options should be
>> created for RA and for DHCPv6.    It should answer questions like where
>> there could be duplication of options, and where there should not be
>> duplication, providing information to all hosts on a link vs per host
>> information, etc.    Draft <draft-troan-6man-universal-ra-option> mentions
>> this topic, but doesn’t provide any specific guidance.   There would be a
>> lot of value in a new document that specifies this.
>>
>> I also think that this document made it clear we need to address the
>> issues with new RA and DHCPv6 options, the hard issues are not the format
>> or encoding of these options.  If the 6MAN working group can accomplish
>> that, then new kinds of RA and DHCPv6 options will be easier to create
>> regardless of the mechanism used to do that.
>>
>> In summary, <draft-troan-6man-universal-ra-option> is not adopted at this
>> time.
>>
>> Bob
>> 6MAN Chair
>>
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------
>