Survey of Possibilities for the Automated Configuration of Large IP Networks
draft-ietf-opsawg-automated-network-configuration-05

Taking over Stewart's discuss as he will be absent fron the telechat....

The authors say:

   It should be noted that some steps in the described process, in
   particular the bootstrapping phase, may not be secure and it is thus
   important to verify the identity of the device and the identity of
   the configuration server when a secure connection to a configuration
   server is established.

Surely bootstrapping should either be out of scope, or listed in the
gapa analysis section as an issue that needs to be addressed

After some discussion and further consideration on this, I'm changing my position to DISCUSS: I don't see where this document is going, what its value is, and how it meets the goals it purports to set out.  Brian's DISCUSS text says it all excellently, so I'll refer to that for more detail.

1. I am unsure of this document's goal.  The title purports it to be a problem statement on the automatic configuration of network devices.  However, most of the document is a taxonomy on the existing methods used to configure the network devices. The abstract makes no mention of being a problem statement and the introduction specifically says it is a taxonomy.  Which is it?  What is the document trying to accomplish?

2. The definition of the inter-domain scenario seems incomplete.  Is there a requirement that the two networks have some type of predefined relationship (e.g., business partnership) in order for the new device to actually connect to its home network?

3. In describing the relative merits of some of the possible solutions to the identified problems, the document attempts to rank those solutions against one another.  However, the relative ranking of those solutions are dependent on each operator's network, administrative model, business goals, etc.  I see no reasonable way that this document can say one solution is better than another.  Those types of statements should be stricken from the document unless you can elaborate why those rankings hold in all situations.

4. The document overall is unclear on what types of devices it is describing when discussing configuration information.  At best, it talks about "large IP networks", but doesn't delineate between types of devices.  For example, is there an expectation that a transit service provider would use this model to configure its core routers?

In my opinion, the title of this document is inaccurate.  Any problem
statement is interleaved with the solution model, the problem is
incompletely described (is this document aimed at configuring any network
device, just customer edge devices, constrained devices; what is the
relationship between the networks in the inter-domain case), and the
problems derive in many cases from the assumed solution.

I *think* there is a useful set of abstract, solution independent
problems somewhere in the document, but I don't think the document is
of value in its current form.

My action to clear this Discuss would be for the working group to
rewrite the document, extracting the problems from the rest of the
solution framework, taxonomy, etc.

Brian very clearly stated several specific issues with the document
and I support his Discuss on those issues.

1) general: it's not until s5 that term "constrained device" is used.  Is this draft targeted specifically at that market segment or the more general case?

2) general: I don't think you should assume that further specifications are required for the gaps you've identified.  I don't want to see this document used as a club later on to specify things that might turn out to not be needed or unwanted.  It makes more sense to say these items require further study.

3) s4: I think that the "requirement" (noting the lower case) for an invariant ID is shared by many enterprise users, but I doubt my mom and dad want that.  Is this targeted at devices to be included in enterprise networks or the general Internet case?