On Wed, Oct 13, 2010 at 08:49:47AM +0200, mohamed.boucad...@orange-ftgroup.com wrote: > Thank you for this clarification.
I think you may have misunderstood - I did not mean that the IESG's main complaint was with the complex normative requirements, I meant that this would be a fair way (I hope) to assess the motivations that inspire the complaint. The direction was pretty clear that we needed to drop one of the two formats. "Alias" options are not technically impossible. I can point to a few RFC's that describe options with partially overlapping or completely aliased configuration state - just providing different formats. They are "IETF improbable" because of the complexity required in their implementation - collectively, we are wary that people will actually follow the (important) directions we include in our protocols, or that we'll even be able to write appropriate directions to begin with. I don't see a way to retain the two formats without also requiring the complex normative requirements (on operators writing their configurations!) as we did in -04. > "it is not advisable to group options that may not be > requested at the same time by the same client under an encapsulated > space." > > Which is not the case of the aftr option. Sub-options are more of a way to encode multiple configuration values of variable length, wherein if the client requests one of the options it is a given the client must also receive the others in order to work. I can't think of an example of this off the top of my head. But the crux of it is that the server will reply with the entire encapsulated space. This isn't really a problem tho, particularly in DHCPv6, because it's just a space optimization issue. It also doesn't work around the problem of client implementation of the different formats. We would still have to require that one of the formats always appears from the server (the simplest, the address option), that the client always supports the simplest option and at its option implements the other formats, and then we'd still wind up with the situation where the client gets the IPv6 address of its AFTR endpoint -and its name- and then goes through all that resolution work to find out if there might be a different address to use. I mostly included the sub-option mechanic as a third option to be complete. It is a habit of mine to enumerate issues to enunciate that we are not arguing a false dichotomy. There is a real dichotomy here - address or FQDN and not both - centered on the discussion of the acceptance (or rejection if you prefer) of complexity in DHCP option format standards. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
pgpRsFGzMT9lY.pgp
Description: PGP signature
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
