Subject: *DRAFT* of minutes from Oslo WG meeting

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Jul 1999 08:07:08 -0400 (EDT)

Here is a draft of the minutes from the Oslo WG meeting.  I've included
both the DHCPv4 and DHCPv6 meeting minutes.  Please respond with comments
by this Friday, 7/30.

- Ralph

=====

The DHC working group met twice in Oslo.  The first meeting was used
for discussion of DHCPv4 issues.  Thanks to Stuart Cheshire for taking
notes for these minutes.  Here is a summary of discussion
items and resolutions:

* DHCP authentication, Droms (for Arbaugh): Droms reviewed most recent
  draft.  WG asked for revision: describe authentication for
  DHCPRELEASE, develop PKI example (Olafur Gudmundsson?), other minor
  fixes (to be submitted by WG).  After revision is submitted, new
  draft will be submitted for WG last call.

* DHCP authentication, Gupta: reviewed recent draft proposing
  "protocol 2" for Droms/Arbaugh authentication.  Gupta proposal is a
  generalization of the Droms/Arbaugh mechanism that supports public
  keys and roaming; new features include:
  - Support for PK authentication
  - Replay counter field replaced with replay-detection field
  - MAC field replaced with authenticator field which may contain PK
    signatures as well as shared-key MAC
  In response to question about merging Droms/Arbaugh and Gupta
  protocols, WG consensus is to leave as two separate protocols.
  Droms/Arbaugh will review Gupta proposal to determine if
  modifications to packet format are warranted to accommodate Gupta
  "replay detection method" field.

* Name service search order, Smith: reviewed recent draft proposing
  new option for specifying name service search order; e.g., NIS+,
  NIS, DNS.  WG reacted favorably and asked for final draft that will

  be submitted for WG last call.

* DHCP-DNS interaction, Stapp: reviewed changes in recent draft: added
  optional use of DNS encoding for FQDN, clarified administrators'
  options in deployment, tightened and clarified language, revise key
  RR protocol.  Narten raised issue of obtaining key RR number; he and
  Stapp will obtain number and then go to last call within a month.

* DHCP failover protocol, Volz: reveiwed changes in most recent draft;
  most significant is exclusive use of TCP. Kinnear will schedule
  teleconferences for: TCP, load balancing, security over next month
  to finish draft before Washington IETF.

* LDAP schema for DHCP, Volz: reported on most recent revision to LDAP
  schema draft.  Volz noted that the schema has several shortcomings
  that a policy-oriented schema might eliminate. Yet, a policy-oriented
  schema would be rather difficult to map to current servers.
  He sees three alternatives for moving forward: 1) continue with current
  direction; 2) move to more policy-based model; 3) scale back to record
  only lease information and not configuration information. Discussion to
  continue on mailing list.

* DHCP over IEEE 1394, Fujisawa: reviewed recent draft.  Fujisawa
  explained key architectural issue that affects use of DHCP: node IDs
  can change at any time; e.g., whenever new device is plugged into
  bus.  Thus, node ID cannot be used for client's hardware address and
  for client identification.  WG discussed use of EUI-64, UUID as
  client identifier and client hardware address for DHCP.  Issues will
  be taken to mailing list for further discussion.

* Futures panel, Droms (for Carney): reviewed recent draft report from
  futures panel.  No comment from WG; will report to Carney and
  determine if draft needs further revision before WG last call.

* WG administrative details, Droms:
  - WG agreed to collapse all DHCP mailing lists into two lists:
    dhcp-v4 and dhcp-v6 
  - No support for user class option; will confirm with message to
    mailing list and then remove from WG charter
  - Bill Westerfield agreed take over server selection option
  - Mark Stapp agreed to complete option code recovery process

The second WG meeting was used for discussion of recent developments

in DHCPv6 process:

* Mike Carney has agreed to become an author of the documents.  He
  will have control of the documents' sources.

* Mike, Jim and Charlie plan to have a revision to the documents
  complete by the Washington IETF.

* The WG agreed on the following plan for completion of the documents:

  - Develop list of issues to resolve; obtain WG consensus that list
    is as complete and appropriate as possible
  - Develop solutions to issues from list; obtain WG consensus that
    solutions are correct
  - Revise document based on solutions
  - Obtain WG consensus that solutions are captured in revisions to
    specification
  - Revise document for WG last call
  - WG last call

* The WG developed an expanded list of goals and delivery target
  dates;

  - List of issues:       8/15/99
  - Solutions to issues: 10/ 1/99
  - Revised draft:       11/10/99 (Washington IETF)
  - Consensus on solutions
  - Revised draft:        3/ 1/00 (Australia IETF)
  - WG last call

* The WG developed the following list of issue areas and developed
  issues in each area.  The areas are:

  - Current technical issues
    * Undiscussed issues from Minnesota WG meeting
      (NOTE: this list of leftover issues will be added to the
       minutes before submission to the IETF. - RD)
    * Unresolved issues from WG last call
    * Releasing resources: too many alternatives?
    * (Section 6) Is the mandate for implementation strategy too
      strong?  Why is XID transaction cache described in such detail?
    * Which messages are not idempotent (and why not)?
    * How does a client request addresses from multiple prefixes?
    * Does the RECONFIGURE mechanism scale w.r.t ACK implosion?  New
      RECONFIGURE reduces messages from 2N to N, but N may still be
      large.
    * In case of a RECONFIGURE failure, loosen text to specify "notify
      administrator" (rather than "log to error log").
    * (Section 6.3.2) Clarify that 'C' bit semantics are to release
       all resources, reallocate only those requested in message.
    * (Section 6.4) What does client do with response; add
      MUST/SHOULD.
  - DHCPv4 features to carry forward/misfeatures to avoid/missing
  features to add
    * Extensibility framework: accommodate future extensions without
      requiring recoding/redeployment of clients
    * Vendor identifier/vnedor-encapsulated options
    * "Echo option" - client retains and echoes option value from
      server
    * Explicit "change server" mechanism
    * Client version option
  - DHCPv4 current work to review
    * Agent options
    * Failover protocol: any features in base DHCPv6 spec that would
      make inter-server protocol easier to write?
    * DHCP-DNS interaction
  - DHCPv6 new features
    * What must client do to support interaction with applications?
    * Consistency across client implementations:
      - List of client-supported options
      - Client can explicitly reject options as
        unsupported/unrequested
      - Alternative actions: what to do if option unrecognized,
        unrequested, ...
      - Requested values: client gives range of desired values
    * Model of "resources" and client-server management; what's the
      "right" model?
      - What is a "resource"?
      - What is "releasable"?
    * How does renubmering work; e.g., through RECONFIGURE?
  - Document structure
    * Organization - unclear when reading; information duplicated, not
      in same part of document, contradictory.  Mike Carney to add
      protocol overview
    * Additional discussion needed about why complicated actions are
      mandated and how they were arrived at.  WG to send input to
      authors about parts of the spec that require additional
      discussion.
    * Consider merging two documents into one.

---

From: [email-masked]
Date: Thu, 29 Jul 1999 10:18:18 -0400 (EDT)

Ralph,

	I am interested in using the User Class option.
	I intend to write a draft describing in which context
	I'd like to use the User Class Option. Then I could
	take over the User Class option draft itself.

	Jerome

	Jerome Privat
	BT Labs

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Jul 1999 11:16:06 -0400 (EDT)

> 	    mailing list and then remove from WG charter

Indeed, I'd like to see the user class option too - I think it's a
good idea.   I'm surprised that there was consensus that it wasn't
needed.   How was the WG meeting attended?

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Jul 1999 13:03:51 -0400 (EDT)

> Microsoft supports the user class option in both Windows 98 and the upcoming
> Windows 2000.  We've found it to be useful for a number of applications.
> We, too, would like to see this be adopted by the WG.

Wow, really?   I have to check this out - how does it work?   Is it in
the initial Win98 distribution, or the update?

Thanks!

			       _MelloN_

---

From: [email-masked] (Greg Rabil)
Date: Thu, 29 Jul 1999 13:52:08 -0400 (EDT)

I've not seen it in Win98, but Windows 2000 Release Candidate 1 definitely
supports User Class.  It is configured using the command-line 'ipconfig'
utility.  Not very secure, though.  For example, what's to stop a user from
defining himself as a desktop system (as opposed to a laptop) and get long
leases, if that is what some admin had configured the server to do (i.e.
give long leases to user class "desktop" and short leases to user class
"laptop").

Greg

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Ted
> Lemon
> Sent: Thursday, July 29, 1999 1:05 PM
> To: Multiple recipients of list
> Subject: Re: *DRAFT* of minutes from Oslo WG meeting
>
>
>

---

From: [email-masked]
Date: Thu, 29 Jul 1999 14:39:32 -0400 (EDT)

See
http://technet.microsoft.com/cdonline/Content/Complete/boes/bo/win2ksrv/technote/dhcpnt5.htm

for details on DHCP for windows2000

Hannah

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Jul 1999 15:43:50 -0400 (EDT)

> Typically, I would imagine you'd want to use this option to have the server
> give a particular set of options or a particular address, etc.  Similar to
> many typical uses of the vendor class option.  I'm not sure I know any
> better way for a client to identify it's user class, but just wanted to
> point out how this is done in Win2000.

Yup.   Thanks!

			       _MelloN_

---

From: [email-masked] (Greg Rabil)
Date: Thu, 29 Jul 1999 15:41:58 -0400 (EDT)

> > Not very secure, though.  For example, what's to stop a user from
> > defining himself as a desktop system (as opposed to a laptop) and
> > get long leases, if that is what some admin had configured the
> > server to do (i.e.  give long leases to user class "desktop" and
> > short leases to user class "laptop").
>
> Nothing whatever.  If you want to use the client-supplied user class
> for authorization, you are barking up the wrong tree.  Using it to
> differentiate between clients so as to make the network run more
> smoothly, on the other hand, is a *good* idea.
>

I wasn't attempting to use user-class for any type of authorization.  Just
trying to point out some possible issues with allowing the end user to
control his/her user class.  BTW, I also agree that the intention of this
option is a good idea, and, in general, I favor the option.

> In the instance you cite, the reason why you want to have shorter
> leases for laptops is so that they renew their leases more often, and
> thus if they are disconnected from one subnet and moved to another,
> they will quickly re-establish IP connectivity.  Also, you get to
> reclaim their lease sooner.  On a well-maintained, DHCP-administered
> network, there really is no advantage to having a longer lease - I
> can't imagine why a user would even notice.
>

Again, I was just siting an example.  Actually, this example is directly
from the Microsoft Whitepaper which describes their reasons for supporting
the user-class option.
Typically, I would imagine you'd want to use this option to have the server
give a particular set of options or a particular address, etc.  Similar to
many typical uses of the vendor class option.  I'm not sure I know any
better way for a client to identify it's user class, but just wanted to
point out how this is done in Win2000.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Jul 1999 15:39:44 -0400 (EDT)

_MelloN_

---

From: Hx Man <[email-masked]>
Date: Thu, 29 Jul 1999 17:58:41 -0400 (EDT)

unsubscribe Mike Lutwick

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Fri, 30 Jul 1999 10:20:30 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
----------------------------------------------------------------------------
Microsoft supports the user class option in both Windows 98 and the upcoming
Windows 2000.  We've found it to be useful for a number of applications.
We, too, would like to see this be adopted by the WG.

Thanks!

Ye

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, July 29, 1999 8:16 AM
To: Multiple recipients of list
Subject: Re: *DRAFT* of minutes from Oslo WG meeting 

			       _MelloN_