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

From: Ralph Droms <[email-masked]>
Date: Thu, 2 Dec 2010 19:12:35 -0500

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2010 23:07:59 +0100

On Thu, Dec 02, 2010 at 07:12:35PM -0500, Ralph Droms wrote:
> 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?

As the document says, we are trying to summarize existing mechanisms
and identifying any gaps. Whether the IETF or other bodies will take
any action to address any of the gaps, we do not know. In the IETF,
this likely depends on whether someone puts a good proposal on the
table and obtains support for the proposal.
 
> 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?

We have not discussed this in the ID. So far, section 5.1 considers
the establishment of link layer connectivity out of scope since this
is pretty much link-layer specific.

> 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.

So would this be a more precise statement:

G1: Definition of non-opaque identifiers that are stable across all
    bootstrap steps in a device for DHCPv6 such as the work described
    in [I-D.dhc-duid-uuid].

> 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.

I think we mention this at the beginning of the paragraph just before
section 5.4. Perhaps this is not clear enough?

> 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.

Do you have a concrete proposal where you want to have this
discussion? I believe some of this covered implicitly in the current
text but perhaps it makes sense to have a more generic discussion of
this aspect at the end of section 2. Is that what you have in your
mind?

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

This reference is used except in section 1 where we talk about the
history and thus reference an older version of DHCP.

> 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.

As mentioned above, section declares the establishment of link-layer
connectivity pretty much out of scope for the document. Our motivation
here is that link-layer technology largely is non IETF technology. Do
you think it is essential to discuss how different link-layers may
allow to establish link-layer connectivity?

Concerning the larger question, I am not sure yet that organizing the
document around the information that needs to be delivered adds
clarity (nor to I think the current organization of steps is "somewhat
arbitrary and ad hoc"). Perhaps you can post a counter proposal so
that I can see why a different structure is less "ad hoc".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>