Skip to main content

Shepherd writeup
draft-ietf-opsawg-automated-network-configuration

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

> (1) the working group is requesting this document to be published as an
informational RFC as identified in the header of the document. We believe that
this is appropriate as it identifies approaches to automatic network
configuration, and does not define any new protocol or standards activities. It
identifies problems in this space, and a set of tools defined by the IETF that
could be used to address those issues. > > (2) > > Technical Summary > > This
memo discusses the steps required to bring a large number of > devices into
service in IP networks in an automated fashion. The > goal of this document is
to list known solutions where they exist, to > point out approaches proven to
be problematic, and to identify gaps > that require further specifications. > >
Working Group Summary > > This document had a long process through the working
group, mainly due to two points. > 1) Was this work actually going to change
behavior of the reader. Was there substantive value in the material presented.
> 2) There was an IPR claim made by one of the Author's employer on the
document. There was discussion about IPR on an informational document. The IPR
claimant clarified that IPR existed around a potential solution to problems
presented by the document (i.e. if the tools mentioned in the document were
"assembled" in a specific configuration to address the issues identified in the
document, then there was the chance that IPR may become involved). This was
discussed and accepted by the working group. > > Document Quality > > As this
document specifies no new standards or MIBs, and is not an implementation
target, there are no interoperability concerns. The document is reasonably well
and clearly written for a practitioner in the space to understand. > >
Personnel > > the document shepherd is Christopher Liljenstolpe, and the AD is
Ron Bonica. > Director? > > (3) The shepherd as run the document through the
extensive nits tool and found no substantive nits. The only outstanding comment
from the tool was reference to one obsoleted RFC, which will be cleaned up by
the authors before publishing. > > (4) The shepherd has no substantial concerns
about the depth of the review, other than the audience that undertook the
review was relatively small. > > > > (5) The working group does not believe
that any other specialized review is necessary of the document. > > (6) The
only concern that the shepherd has about the document is the relatively limited
discussion about the contents of the document that took place as well as what
could be a relatively limited impact of the document itself (i.e. how much
change in behavior or process that the document will actually engender). > > (7
& 8) The working group is aware of a (revised) IPR claim on this document. We
believe that BCP 78 & 79 have been addressed. It is the understanding of the
working group that the IPR claim does NOT actually make a claim against the
discussion in this informational document. It is our understanding that it is
more of a "warning" that there exists a body of IPR that may be infringed on if
some subset of the tools discussed in the document are assembled in a specific
way to address one or more of the issues identified by the document. Any entity
working on addressing the issues identified by this document should be aware of
potential IPR infringements. > > (9) This document has the strong consensus of
a subset of the working group, with the remainder of the working group silent.
> > (10) There have been no threats of appeal or other examples of substantial
friction over this document. > > (11) As discussed above, a thorough nit check
was performed by the shepherd. The only comment from the tool was one reference
to an obsoleted RFC. This has been passed to the authors for consideration. > >
(12) No review is necessary for MIBs URIs, etc. > > (13) All references have
been classified > > (14 & 15) There are no normative references. > > (16) This
document, if published, will change NO existent RFC's > > > (17 & 18) This
document makes NO requests of IANA. > > (19) There is NO formal language in
this document. >
Back