Subject: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Dec 2008 05:51:55 -0500

REMINDER: This WG last call will end on Dec 19.  We have only received  
one review of the document, and need several more reviews before the  
document can be advanced to the IESG.

This message announces a WG last call on "The DHCPv4 Relay Agent
Identifier Suboption" <draft-ietf-dhc-relay-id-suboption-04.txt>.  The
last call will conclude at 1700PDT on December 19, 2008.  This
document is intended for publication as a Proposed Standard.  The -04
revision of the document includes changes based on the comments
received during the previous last call.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

draft-ietf-dhc-relay-id-suboption-04.txt defines a new Relay Agent
Identifier suboption for the Dynamic Host Configuration Protocol's
(DHCP) Relay Agent Information option.  The suboption carries a unique
identifier configured or generated at the relay agent.  The suboption
allows a DHCP relay agent to include the unique identifier in the DHCP
messages it sends.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-04.txt

- John Brzozowski, Ralph Droms
   dhc WG chairs

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

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 16 Dec 2008 13:03:09 -0800

> http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-04.txt

I support the draft moving forward, just a minor wording thing;

The type code zero is referred to as being reserved and MUST NOT be
used, but the IANA considerations section seems to allocate this code
to be named '_NULL'.  I'd rather see this named _RESERVED, or placed
in a 'reserved range', as that seems less confusing;

		0	Reserved
		1	RELAY_IDENTIFIER...etc

I think the draft can move forward with or without any attempt to
address this.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Tue, 16 Dec 2008 16:03:40 -0500

Thanks, David - I'll make that change to clarify the IANA section.

Regards,

Mark

David W. Hankins wrote:

0 Reserved
1 RELAY_IDENTIFIER...etc

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 17 Dec 2008 09:29:04 +0530

I have read this document and support to move it to next level.

Thanks,
Bharat
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ralph Droms [[email-masked]]
Sent: Tuesday, December 16, 2008 4:21 PM
To: dhc WG
Subject: [dhcwg] REMINDER: dhc WG last call on  draft-ietf-dhc-relay-id-suboption-04.txt

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 17 Dec 2008 17:08:05 -0500

Ralph, et.  al.

I have performed a detailed review of this document as I agreed
to do when we met in Minneapolis.

Since this was just re-issued as an -05.txt version, I reviewed
the -05.txt version.

It is acceptable as it is, and the several comments that I make
below aren't intended to hold up the document's progress.  If we
can get some of these points addressed during some of the editing
passes that are ahead, that would be nice but not required.

1.  In section 3.2, Bulk Leasequery, the world has moved on since
these words were written.  There is currently a
draft-kkinnear-dhc-dhcpv4-bulk-leasequery-01.txt which is the
merged version of the two drafts mentioned in the draft under
review.  I believe that it has been successfully accepted as a
work item for the DHC WG, and thus the next version (which will
be out as soon as I fold in current comments) will be
draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt.  You could
reference that now, or the draft-kkinnear.*-01.txt one, but it
would be nice to only reference one draft since they have now
merged.

2.  In section 5, Relay Identifier Types, it would be useful to
simply include a table with the defined numeric values for
RELAY_IDENTIFIER_DUID and RELAY_IDENTIFIER_ASCII.  IANA isn't
going to change these values, and it seems difficult (and
unusual) to send the implementor off to the IANA section to find
the actual values of these constants.

3.  In section 7, Identifier Stability, it might be useful to
discuss something about Identifier Continuity in the context of
stability.  You have used the Industrial Ethernet as a use case
(which I think was a good idea), and one of the difficulties of
this particular use case is what to do when a relay agent has to
be replaced.  This would seem to be the place to specify some
behavior as to how to handle one device taking over for a failed
device.  It would seem to me that allowing (or requiring) devices
to be able to generate a DUID that matches that of a previous
plug-compatible (or at least port-compatible) device might be
useful here.

Other than those non-required changes, I found no problems with
the document and feel it should move forward in the
standardization process.

Regards -- Kim

---

From: Mark Stapp <[email-masked]>
Date: Thu, 18 Dec 2008 17:29:30 -0500

Hi Kim,

thanks for the great comments. I'm posting an updated version of the draft.

Kim Kinnear wrote:
> these words were written. [...]
>   
done - converged to the one-true-draft.
> the actual values of these constants.
Ah - I've actually gotten pushed the other way recently about the 
handling of IANA values. The current 'best practice' seems to be to keep 
all the actual number assignments in one place - in the IANA section - 
and to use tokens elsewhere in the document. Unless you feel it's really 
confusing, I'd like to leave the IANA material as-is: I'm afraid I'd 
just have to change it back during IESG review.
> plug-compatible (or at least port-compatible) device might be
Yes, thanks - that's a very good point. I've added another paragraph to 
that section to describe the situation where a relay device is replaced, 
and explain that this is a reason for implementors to permit admin 
configuration of the identifier value.

Thanks,
Mark