Re: [dhcwg] DHC WG charter

[Thomas Narten <[e-mail]>]

some comments on the charter:

Nits:

Would be good to have a short intro sentence at the start something
like:

The base DHC protocol is documented in RFCs 2131 and 2132 as well as a
number of related extensions and options (e.g., RFC 3118). The working
group has the following primary objectives ...

> * Develop a threat model and analysis of the authentication
>    protection provided by RFC3118; specific issues to be addressed
>    include:
>    - Improved key management and scalability

Sounds here like your already jumping ahead to the requirements for
new protocols. I.e., shouldn't this phase be focused on undertstanding
limiations of the current mechanisms? Is this just a wording issue?

>    - Security for messages passed between relay agents and servers
>    - Threats of DoS attacks through FORCERENEW

> * Develop requirements for any new protocols to address threats or
>    other enhancement identified by the threat model and analysis of
>    3118

What's missing above is a clear statement that this WG will develop
new authentication mechanisms that address the deployability problems
with the current schemes (whether through an extension to 3118 or
something else). Or that it will address the relay-agent to DHC server
path.

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

General comment on options (both IPv4 and IPv6). I'd like the charter
to clearly indicate that the DHC WG will be reviewing options to make
sure they are  consistent with the protocol, other option usages, etc.

In terms of reviewing  options for their semantic contents, that
will be done by subject matter experts, which may well not be in this
WG. This WG is not to take on options as WG documents until such an
outside expert has been identified and, e.g., the relevant  WG has
agreed on the need for such an option. What I'd like to avoid is
having the DHC WG spend time on options for which there isn't a clear
customer. 

>    - Encourage independent implementations and report on
>      interoperability testing
>    - Revise specification and publish for acceptance as Draft Standard
>      by 10/18/2002

> * Write an analysis of the DHCP specification, including RFC2131,
>    RFC2132 and other RFCs defining additional options, which identifies
>    ambiguities, contradictory specifications and other obstacles to
>    development of interoperable implementations.  Recommend a process
>    for resolving identified problems and incorporating the resolutions
>    into the DHCP specification.

The way its written above, sounds like one big fat hard-to-write
document. :-) Can't we do something simpler,  such as just have folks
write IDs that take on specific  issues and advance  them as
standalone RFCs (as appropriate), incorporating them into the base
spec when the base spec is republished? I'm worried that the above
reads like a lot of work that no one will be foolish enough to sign up for.

> * Complete the specification and publish work in progress as
>    standards:
>    - Failover protocol
>    - DHCP/DDNS interaction
>    - SNMP MIB
>    - Host name options
>    - Leasequery
>    - Other client and relay agent options

Are there IDs for all of the above? If so, citing them would be good.

Also, I don't like the "other client and relay agent options" as it is
too open ended. I think the WG needs a way of vetting potential
options before the WG takes them on officially.

> * Review new options for DHCP, as deemed appropriate by the working
>    group and/or the Internet area directors

See above.

Thomas
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg