RE: [dhcwg] DHC WG charter

Thomas, Ralph, Jim, Bernie, et al.,

> > The working group has the following primary objectives:
>
> > * Develop additional authentication protocols within the framework
> >   defined in RFC3118, along with other mechanisms to mitigate the
> >   threat of attacks on DHCP clients and servers:
> >   - New RFC3118 protocols to address improved key management and
> >     improved scalability
>
> I think the charter should be more specific here. What new protocols
> are needed? What problems need to be solved? The above is just a blank
> check to do unspecified work (not good).
>
...I think the first question to ask is (1) what problems need to be solved?
While I agree with Ralph that the result of answering (1) will probably be
to identify additional application protocols required within the RFC3118
framework, I believe we need to proceed by conducting a threat analysis,
which I would suggest should be our second question:  (2) what threats to
secure, reliable network configuration are likely or possible to occur?  A
third question might be (3) how does any security or authentication proposal
fit with other work of the IETF?

*Snip!*

> >   - Consider solutions for specific threats such as use of nonce
> >     identifier to defend against DoS attacks through FORCERENEW from
> >     off-path attackers
>
> This might be good, but it seems like a prerequisite is to have a
> documented threat analysis. What are the primary threats to DHCP?
> Which ones are the ones that are important to address? Only then does
> it make sense to think about specfic solutions.
>
...agreed, a threat analysis probably should be first

> > * Complete the specification of DHCP for IPv6 (DHCPv6):
> >   - Gain acceptance and publication of current Internet Draft as
> >     Proposed Standard
> >   - Develop and publish specifications for options and other
> >     extensions to DHCPv6, including those already published as
> >     Internet Drafts:
> >     + "DNS Configuration Options for DHCPv6"
> >     + "Time Configuration Options for DHCPv6"
> >     + "NIS Configuration Options for DHCPv6"
> >     + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6"
> >     + "Load Balancing for DHCPv6"
> >   - Encourage independent implementations and conduct interoperability
> >     testing
>
> I don't think this needs to be called out in the charter. WGs don't do
> interoperability testing per se. But interoperability reports are
> needed for advancing documents along the standards track.
>
...I disagree slightly, Thomas, in that I believe it is important for the
working groups to encourage multiple implementations and interoperability
testing precisely because that is the means to substantiate a call for
advancement.

> >   - Revise specification and publish for acceptance as Draft Standard
> >     by 6/30/2002
>
> >   - Develop extensions to DHCPv6 for prefix delegation, DNS
> >     configuration, etc.
>
> I'm not sure I agree with this. I think the DHC needs to stick with
> its core expertise, which is the DHC core protocols, and reviewing
> options motivated from outside the WG from the perspective of being
> consistent with standard DHC operating practice.
>
...again, answering question (1) should provide the necessary clarification
to determine what extensions are needed.

*Snip!*

> So, I think better charter wording would say that the WG will review
> options whose impetus comes from other WGs. A number of the specific
> options mentioned above are really motivated by other WGs.
>
...agreed

> > * Revise and submit the DHCP specification for acceptance as a Full
> >   Standard
>
> I guess I'm a cynic. If there is no realistic plan for doing this, I'd
> say leave it out of the charter.
>
...what would constitute a realistic plan in your view?  A full-blown review
of all DHCPv4 options for currency and usefulness?  Sunsetting or
deprecation of unused options, features, and functions?   Time limits for
generating DHCPv6 extensions?  A freeze on new protocol development?  My
cynicism runs the other way:  if it isn't included in the charter, I'm not
convinced that either the -v4 or -v6 protocols would ever make it to Full
Standard.

> The charter should not be a kitchen sink of all possible work
> items. It should capture the priority items the WG will work on over
> the next 12 months. One can easily recharter if something interesting
> pops up that should get attention.
>
...agreed

> > * Complete the specification and publish work in progress as
> >   standards:
> >   - Failover protocol
> >   - DHCP/DDNS interaction
> >   - SNMP MIB
>
> What is the MIB item? Do we really need it?
>
...every time (at least 3 times) I asked the attendees at a WG meeting if
this work should continue towards adoption, the voice vote was affirmative.
I still get occasional mail from people who have begun implementation and
have questions or request clarifications -- that was the source of updates
to the last revision of the I-D.  On the other hand, the DNS extensions
working group just dropped the idea of ever defining a standard server or
resolver MIB as unwanted, even though I know of 5 different vendors who
provide a DNS server MIB.  I also am aware of at least 3 private DHCP server
MIBs, so somebody out there wants it!  However, if we can't get this to
working group last call before the December meeting, I intend to withdraw
the draft from the I-D editor.

--Barr

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg