The contents of the Line Identification Destination Option are essentially opaque.
Although this may allow a wide range of router implementations, in practice it leads to a situation where new implementers must reverse-engineer the dominant implementation in order to be assured of compatibility. An opaque field allows a wide range of router implementation practice at the cost of ease of use of the field in provisioning databases. An implementation of a provisioning database which can configure a range of routers has to ask for the Identification Destination in hexadecimal. If the contents of the field are in practice a MAC address there may be a repetition of the experience with the RADIUS's Calling-Station-Id where a lack of definition of the content of the field leads to programs with two or so pages of parsing code to extract a wireless device's MAC address. If the contents of the field are in practice an interface name then perhaps ifIndex would be more suitable. If the contents of the field are in practice a customer provisioning identifier then perhaps the field could be specified as a string so that programmers know that the field can be typed or printed rather than hexdumped. Some care should be taken to identify the character set, as it is unlikely to be UTF-8. If the authors decide that opaque is desirable then they should define the textual representation of the field. That way the contents of the field are defined identically across different manufacturers' router configuration languages, ISP provisioning databases, etc. Best wishes, Glen -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
