Subject: [dhcwg] I-D Action:draft-schoenw-opsawg-nm-dhc-00.txt

From: [email-masked]
Date: Mon, 18 Oct 2010 13:45:02 -0700 (PDT)

FYI...

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Network Management
	Author(s)       : J. Schoenwaelder
	Filename        : draft-schoenw-opsawg-nm-dhc-00.txt
	Pages           : 9
	Date            : 2010-10-18

This document defines new Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) options that contain a list of IP addresses that can be
used to locate network management services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schoenw-opsawg-nm-dhc-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Oct 2010 14:33:47 -0700

I just read over your draft.   It defines a new suboption space.   Can you explain why you chose to do this rather than just defining two options?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Oct 2010 19:08:46 +0200

On Mon, Oct 18, 2010 at 02:33:47PM -0700, Ted Lemon wrote:

> I just read over your draft.  It defines a new suboption space.  Can
> you explain why you chose to do this rather than just defining two
> options?

I think there is no special reason, except me believing that DHCPv4
option number space is somewhat limited. If there is guidance not
to worry about this, we could eliminate the suboption space.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 21 Oct 2010 09:44:29 -0500

It looks to me like there could be additional services in the future so
perhaps a sub-option isn't such a bad idea? But in the end it may not
make much difference as it probably requires the same amount of work
either way (i.e., a draft/RFC). It is probably more of a question as to
whether there will be just a few or many over time.

The advantage of using a separate option is that the client can indicate
the ones it supports (in the Parameter Request List (v4) or ORO (v6))
and the server can return just those that the client supports. And, this
means the server doesn't have to send ones that can't be used. (You have
this support documented, but it comes at the cost of having to add
special logic in the server, which isn't a good idea.)

The advantage of using a suboption is that if you intend the client to
use only ONE mechanism and thus want to specify the priority, you can.
With options you can't really do this since the order of options in the
PRL/ORO and in the response is not specified.

The following text is also a bit odd:

   A server MAY use the sub-options in the received Network Management
   IPv4 Address Option from the client's message to restrict its
   response to the client requested sub-options.  In the case when the
   server cannot find any servers satisfying a requested sub-option, the
   server SHOULD return the network management Option with that sub-
   option and the length of the sub-option set to 0.

This seems to require (at least to adhere to the SHOULD) special
processing in the DHCP server. This does not seem like a good idea to me
... and will slow the adoption of the option since it requires servers
to be modified to do this processing (at least, if they want to adhere
to the SHOULD). If you want this option to be quickly adopted, far
better to simply allow it to be configured statically on a server and
sent to the client if requested. (I guess likely the SHOULD is
conditional on the MAY and thus this is a non-issue). Is there a reason
why you want the 0 length sub-option to be returned (instead of no
suboption)? What's the value in the difference between the two
responses?

While I admit I didn't read every word of the document, it isn't clear
to me what the purpose here is (yes, I figure it is if SNMP-TRAP
specified, send traps to this host and/or if SYSLOG is specified, send
SYSLOG messages to this host).

And, you indicate "Servers MUST be listed in order of preference and the
client should process them in decreasing order of preference"? But how
does that work? SNMP traps (at least last I looked, which has been a
while ago now) are UDP and not acknowledged? And, the references include
the SYSLOG over UDP draft which may also have no acknowledgments?
(There is no use of this reference in the text?) So, if more than one
address is specified, how is the 2nd address ever to be used (I guess
the client could use it if it gets ICMP[v6] destination unreachable
messages?). Perhaps this was only for those cases where TCP or some
other connection oriented protocol is to be used? But, that raises other
issues, such as how does the client know whether to use UDP or TCP (or
whatever)? Perhaps you need a SYSLOG-over-UDP and SYSLOG-over-TCP
(sub)options?

And, it also seems that this isn't always complete information - for
SNMP-TRAP isn't there a community name to specify (I guess it would be
'public' if none)?

Bottom line - I think you should, as Ted suggested, strongly consider
separate options unless you expect a lot of these services and expect
clients to be able to use lots at once. And remove any need for special
server processing - if options are used, the server simply returns any
ones it has configured that the client requested in the PRL/ORO.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Juergen Schoenwaelder
Sent: Tuesday, October 19, 2010 1:09 PM
To: Ted Lemon
Cc: [email-masked] Group
Subject: Re: [dhcwg] I-D Action:draft-schoenw-opsawg-nm-dhc-00.txt

/js

dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg