Ran, Thanks. I was reaching a conclusion based on what someone said at the last 6man session. Given that opaque is not what I thought, your suggestion makes sense to me.
Bob On Dec 6, 2011, at 11:35 AM, RJ Atkinson wrote: > > Bob, > > My read of the relevant RFCs is that the > DHCP Line-ID option specifies the use of the "NVT" > character set. > > The character set specification is implicit, applying > to all DHCP options, rather than having been written > explicitly for this single DHCP option. One has > to really study the full set of DHCP RFCs > (i.e. the full daisy-chain of RFC citations from > the References backwards) to see this, but it is > consistent with every DHCP implementation that > I can identify. > > I can't find ANY DHCP implementations that permit > "arbitrary bytes" to be entered into the Line-ID option > field. I can't think of any DHCP implementation that > permits, for example, LINEFEED or CARRIAGE-RETURN > to be entered into ANY DHCP-related field. Many > have problems with inputs other than printable > characters from ISO-8859, for example. > > The word "opaque" in the DHCP Line-ID option > specification refers to the packet processing > for the DHCP packet, not to the contents of > the field or how that field is entered > (presumably via a CLI or perhaps web page someplace) > or how that field is to be displayed to humans. > > The DHCP Line-ID option does not use the word > "opaque" to indicate absence of a character set. > That is a mis-reading of the DHCP RFC set. > > As a former ISP person, I can assure that the > Line-ID values absolutely DO get displayed > to operators and others in network operations. > It is important to be able to configure the > Line-ID values and to view them in order to > troubleshoot real networks (e.g. a DSL deployment). > > So the assumption that the DHCP Line-ID option > does not have any specified character set is > not actually correct. > > Now, if one's goal is *strict* compatibility with > the DHCP Line-ID option, then the NVT character > set (originally specified in very early RFCs) > ought to be specified. > > I think, however, it would be reasonable to choose > some alternative such as US-ASCII, ISO-8859-1, > or (maybe -- possibly more risky given existing > DHCP implementations -- but more globally suitable) > UTF-8. > > Yours, > > Ran > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
