[OPSAWG] Review of draft-tsou-opsawg-network-configuration

[Ralph Droms <[e-mail]>]

Comments based on my review of draft-tsou-opsawg-network-configuration...

What is the purpose of the document?  I think it is to summarize existing configuration mechanisms as several levels and identify gaps.  Who is the audience?  Will the document be used to motivate new work that would be generally applicable to joining any device to a network or is it a reference doc from which a particular group (e.g., 3GPP) will devise a more limited-scope mechanism?

How does a device decide among alternative networks to join?  E.g., an 802.11 device may see multiple networks with multiple SSIDs; how does it decide which to join?

I think you have the definition and use of DUID-UUID and UUID a little confused.  UUID is already available as a unique, stable device ID.  The DUID-UUID is a derivative ID solely used for DHCPv6.  Therefore, in G1 I think all that needs to be newly defined is the DUID-UUID for DHCPv6.  Also, the problem with DUIDs and DHCPv6 is not so much the lack of a stable identifier - DUIDs are, by definition in RFC 3315, stable - as the lack of a non-opaque identifier that is constant across all bootstrap steps in the device.

You mention the use of DHCP for several bits of configuration information.  DHCP is likely not to be useful in the inter-domain case as the device's Service Provider is not likely to have the ability to configure the DHCP parameters returned to the device by Service Provider X.

Which brings to mind an aspect of configuration that might be useful to consider  for your document: which parts of the configuration are established independently by the device and reported to the Service Provider and which are required to be delivered from the Service Provider to the device.  For example, in the inter-domain case, the specific IP address used by the device is provided by the remote SP and needs to be delivered to the device's SP, while pointers to other services and applications in the device's SP network must be delivered from the device's SP to the device.

RFC 2131 is a more current reference to cite for DHCPv4.

This last comment is somewhat vague and I'll need to re-read the document to improve the comment.  The organization of the steps the mechanisms seems somewhat arbitrary and ad hoc.  Is it possible to organize the document around the specific pieces or types of information, and then tie in the ways in which that information can be delivered?  For example, relating back to my question about which network to join, the device needs some sort of network identifier, which can be delivered in a variety of ways.  One of the mechanisms for passing information, which I don't think you mentioned, is through physical proximity such as holding the device next to a wireless AP; when both devices flash an external LED, the device has joined the right network.

- Ralph