[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Conclusion of Adoption Call for <draft-troan-6man-universal-ra-option>
From:       Bob Hinden <bob.hinden () gmail ! com>
Date:       2021-09-28 17:33:59
Message-ID: C3B0E3AE-0765-4DCF-A423-A86ECC5E290C () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmFTUgcACgkQrut0EXfn
u6jUPwgAvefDYzwn+zcF8bpkACyMvOQqGagusoCE8TDPwqYxcThJjfh/64sUQUvH
R2ZW8PIhZ1zGu3MpTL8IPkxwOBTbUEZEDHfXkI7UG19YHi3NAA4X36f5n3FfBIM/
JdeKxq6Jvb87MZzBhAly7zdo9Ys7pOqf1IGwT7JYfG0z1jQ4HuOlm1y/hyVVq4Bq
uf/++dBwA4rOKgf7q2wol2fSc0lAiv2FECfuZeMkGnIVVyON4Kri4rtExyGN/ygT
yqcrKAq8WpWMRLLgMH3As9TMomsbdj6wS/hcVyLzOtUAJmnFn/pPlKJVfAP2p65u
zzPoihrVbvKLM6YRTYTI0Pcy4A5Sjw==
=MKWu
-----END PGP SIGNATURE-----


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]