The DSL Forum has defined that all devices that expect to be managed by the TR-069 interface be able to generate an identifier as described in the text I've copied below. It also has a requirement that, going forward, routers that DHCP to the WAN use RFC 4361, DHCP option 61, to provide the DHCP server with a device identifier. The text below also describes the format of that option 61 identifier. OUI is as defined in http://standards.ieee.org/faqs/OUI.html . Product Class and Serial Number are defined by the vendor of the CPE. ... the CPE MUST use a username/userid that is globally unique among all CPE manufacturers. Specifically, the CPE username/userid MUST be in one of the following two formats "-" "-" "-" The , , and fields MUST match exactly the corresponding parameters included in the DeviceIdStruct in the Inform message, as defined in Appendix A, except that, in order to guarantee that the parameter values can be extracted from the username/userid, any character in the and that is not either alphanumeric or an underscore ("_") MUST be escaped using URI percent encoding, as defined in RFC 3986 [9.1]. 2. PPP login info is only known by the router. It will generally not be known by target devices. It will also not be usable in visited networks, which are unable to verify against home RADIUS servers. I recommend not using PPP login info for our purposes. 3. VPI/VCI on the target side is generally only seen by the DSL modem and not the target (and not the router, if the router doesn't have a built in DSL modem). Almost all routers in the US use 1 of 2 VPI/VCI values: 0/35 and 8/35. This is terminated at the DSLAM, which uses a different VPI/VCI (per end customer) to connect to the ATM switch. But only the network provider is able to map VPI/VCI values all the way through its network. Also, with the coming of VDSL, ATM will slowly be phased out in favor of Ethernet.Which is all a long way of saying that I think VPI/VCI is fairly useless for our purposes. 4. Beware of Multicast. In testing, we have discovered that Multicast support and implementation (and quality of implementation) varies greatly from router to router on legacy devices. If you choose to try a multicast option, I recommend against using the limited and administratively scoped ranges (which includes the address used by UPnP). In our DSL Forum requirements for routers, going forward, we have the following requirements: a) The device MUST be configurable to prevent sending IGMP messages to the WAN interfaces for specified multicast groups or ranges (such as 239.0.0.0 through 239.255.255.255, which are limited scope or administratively scoped addresses). b) The device MUST default to not sending IGMP messages for 239.0.0.0 through 239.255.255.255 to the WAN interfaces. that entity, the ISP will map to location based on IP address, and its response will be "I have assigned this IP address to device(s) entering the access network at this location". Note that IP address is not an identifier here. I hope no-one questions this use of IP address. We need to be very clear on the use of IP address as identifier of the requesting entity vs. the use of IP address as a mapping to a location. I have confidence in our ability to map IP address to the location where devices using that IP address enter the access network. ---------- http://www.homephonewiring.com/nid.html https://www.customerservice.att.com/assets/pdf/repair_ts_guide.pdf Basically, it's a box on the side of the house/apartment building. Inside it, the home wires are physically connected to the telco wires. They also have little RJ-ll phone plugs, where you can plug in a phone directly and test whether your phone service works from there. Or you can plug in a DSL modem and see if it works from there (assuming DSL service). If service works at the NID but not inside, the homeowner is responsible for repairs.