Skip to main content

Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
draft-ietf-dhc-vendor-suboption-00

Revision differences

Document history

Date Rev. By Action
2012-08-22
00 (System) post-migration administrative database adjustment to the No Objection position for Bert Wijnen
2012-08-22
00 (System) post-migration administrative database adjustment to the No Objection position for Alex Zinin
2005-05-25
00 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-05-23
00 Amy Vezza IESG state changed to Approved-announcement sent
2005-05-23
00 Amy Vezza IESG has approved the document
2005-05-23
00 Amy Vezza Closed "Approve" ballot
2005-05-23
00 Margaret Cullen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman
2005-05-23
00 Margaret Cullen Note field has been cleared by Margaret Wasserman
2005-05-23
00 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen
2005-05-22
00 Alex Zinin [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin
2005-05-22
00 Margaret Cullen
RFC Editor Note proposed to address discusses:

To: "Wijnen, Bert (Bert)" , Alex Zinin
From: Margaret Wasserman
Subject: Fwd: draft-ietf-dhc-vendor-suboption-00.txt
Cc: Ralph Droms

No one …
RFC Editor Note proposed to address discusses:

To: "Wijnen, Bert (Bert)" , Alex Zinin
From: Margaret Wasserman
Subject: Fwd: draft-ietf-dhc-vendor-suboption-00.txt
Cc: Ralph Droms

No one has raised any objection to the proposed RFC Editor note (below), so I have entered it in the tracker.  Bert and Alex, could you check if it addresses your concerns and, if so, remove your discusses on this document?

Thanks,
Margaret

Date: Thu, 12 May 2005 13:07:35 -0400
To: Ralph Droms , Stig Venaas , mjs@cisco.com, raj@cisco.com, athenmoz@cisco.com
From: Margaret Wasserman
Subject: draft-ietf-dhc-vendor-suboption-00.txt
Cc: Russ Housley , Alex Zinin
Bcc:
X-Attachments:


Hi All,

We considered draft-ietf-dhc-vendor-suboption-00.txt on the IESG telechat today.

There were two discusses from Bert and Alex and a comment from Russ (included below).  If it is okay with you guys, I proposed to fix these minor issues with the following RFC editor note:

  (1) Change the spelling of IPsec throughout:

  OLD:
  IPSEC

  NEW:
  IPsec
  ---

  (2) At the end of section 3, change:

  OLD:
  The Vendor-specific data are of course provider-specific.

  NEW:
  The Vendor-specific data are of course vendor-specific.
  ---

  (3) Remove the following text:

  OLD:
  DHCP server vendors are encouraged to offer their administrators some
  means of configuring the use of data from incoming Vendor-Specific
  suboptions in DHCP decision-making.

  NEW:
 

Are there any objections to this plan?  Bert and Alex, would this resolve your discusses?

Margaret

---

IESG Discusses and Comments:

Russ Housley:
Comment:
[2005-05-09]
  In section 7: s/IPSEC/IPsec/

Bert Wijnen:
Discuss:
[2005-05-12] End of sect 3 I see:
  The Vendor-Specific data are of course provider-specific. This
  specification does not establish any requirements on the data in the
  suboption. Vendors who make use of this suboption are encouraged to
  document their usage in order to make interoperability possible.

In my reading I understand a vendor to be someone like Lucent and
a provider someone like Verizon. So what does the 1st sentence above mean?

Alex Zinin:
Discuss:
[2005-05-11] I couldn't let this one slip:

  DHCP server vendors are encouraged to offer their administrators some
  means of configuring the use of data from incoming Vendor-Specific
  suboptions in DHCP decision-making.

The danger here is that the document suggests to encourage vendors to
encourage administrators to _guess_ what different vendor-specific
suboptions mean, while they are not necessarily properly documented.
Remove this one?
2005-05-22
00 Margaret Cullen [Note]: 'Waiting for Bert and Alex to respond to RFC Editor Note proposal (see below).' added by Margaret Wasserman
2005-05-13
00 (System) Removed from agenda for telechat - 2005-05-12
2005-05-12
00 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2005-05-12
00 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-05-12
00 Bert Wijnen
[Ballot discuss]
End of sect 3 I see:
  The Vendor-Specific data are of course provider-specific. This
  specification does not establish any requirements on …
[Ballot discuss]
End of sect 3 I see:
  The Vendor-Specific data are of course provider-specific. This
  specification does not establish any requirements on the data in the
  suboption. Vendors who make use of this suboption are encouraged to
  document their usage in order to make interoperability possible.

In my reading I understand a vendor to be someone like Lucent and
a provider someone like Verizon. So what does the 1st sentence above mean?
2005-05-12
00 Bert Wijnen
[Ballot discuss]
End of sect 3 I see:
  The Vendor-Specific data are of course provider-specific. This
  specification does not establish any requirements on …
[Ballot discuss]
End of sect 3 I see:
  The Vendor-Specific data are of course provider-specific. This
  specification does not establish any requirements on the data in the
  suboption. Vendors who make use of this suboption are encouraged to
  document their usage in order to make interoperability possible.

In my reading I understand a vendor to be someone like Lucent and
a provider someone like Verizon. So what does the 1st sentence above mean?
2005-05-12
00 Bert Wijnen
[Ballot discuss]
End of sect 3 I see:
  The Vendor-Specific data are of course provider-specific. This
  specification does not establish any requirements on …
[Ballot discuss]
End of sect 3 I see:
  The Vendor-Specific data are of course provider-specific. This
  specification does not establish any requirements on the data in the
  suboption. Vendors who make use of this suboption are encouraged to
  document their usage in order to make interoperability possible.

In my reading I understand a vendor to be someone like Lucent and
a provider someone like Verizon. So what does the 1st sentence above mean?
2005-05-12
00 Bert Wijnen
[Ballot discuss]
End of sect 3 I see:
  The Vendor-Specific data are of course provider-specific. This
  specification does not establish any requirements on …
[Ballot discuss]
End of sect 3 I see:
  The Vendor-Specific data are of course provider-specific. This
  specification does not establish any requirements on the data in the
  suboption. Vendors who make use of this suboption are encouraged to
  document their usage in order to make interoperability possible.

In my reading I understand a vendor to be someone like Lucent and
a provider someone like Verizon. So what does the 1st sentence above mean?
2005-05-12
00 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to Discuss from Undefined by Bert Wijnen
2005-05-12
00 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2005-05-12
00 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-05-12
00 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-05-11
00 Alex Zinin
[Ballot discuss]
I couldn't let this one slip:

  DHCP server vendors are encouraged to offer their administrators some
  means of configuring the use …
[Ballot discuss]
I couldn't let this one slip:

  DHCP server vendors are encouraged to offer their administrators some
  means of configuring the use of data from incoming Vendor-Specific
  suboptions in DHCP decision-making.

The danger here is that the document suggests to encourage vendors to
encourage administrators to _guess_ what different vendor-specific
suboptions mean, while they are not necessarily properly documented.
Remove this one?
2005-05-11
00 Alex Zinin
[Ballot discuss]
I couldn't let this one slip:

  DHCP server vendors are encouraged to offer their administrators some
  means of configuring the use …
[Ballot discuss]
I couldn't let this one slip:

  DHCP server vendors are encouraged to offer their administrators some
  means of configuring the use of data from incoming Vendor-Specific
  suboptions in DHCP decision-making.

The danger here is that the document suggests to encourage vendors to
encourage administrators to guess what different vendor-specific
suboptions mean, while they are not necessarily properly documented.
Remove this one?
2005-05-11
00 Alex Zinin [Ballot Position Update] New position, Discuss, has been recorded for Alex Zinin by Alex Zinin
2005-05-11
00 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-05-11
00 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-05-11
00 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-05-10
00 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2005-05-10
00 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-05-09
00 Russ Housley [Ballot comment]
In section 7: s/IPSEC/IPsec/
2005-05-09
00 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-05-08
00 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-05-08
00 Margaret Cullen [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman
2005-05-08
00 Margaret Cullen Ballot has been issued by Margaret Wasserman
2005-05-08
00 Margaret Cullen Created "Approve" ballot
2005-05-08
00 Margaret Cullen State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman
2005-05-08
00 Margaret Cullen
Submission Questionnaire

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward …
Submission Questionnaire

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes and yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

The document has received adequate review from key WG members.  It has
not been reviewed by non-WG members; however, it is based on RFC 3925
and does not require external review.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

The document required a second WG last call to obtain sufficient
support for sending it to the IESG.  During the second WG last call,
the document was recommended for forwarding to the IESG by 6 or 7 WG
members and there were no recommendations against forwarding the
document.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

The document may have been produced by a slightly out of date version
of xml2rfc and some of the boilerplate is close but not exactly as
required.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

This document defines a suboption for the Dynamic Host Configuration
Protocol (DHCP) relay agent information option (RFC 3046). The
Vendor-Specific Information suboption allows a DHCP relay agent to
include vendor-specific information in DHCP messages it forwards, as
configured by its administrator.  The definition of a suboption that
carries vendor-specific information allows vendors and network
administrators to carry additional information in options that have
not been accepted as an Internet Standard.  This relay agent
information option suboption is similar to the Vendor Identifying
Vendor Option defined in RFC 3925.

  - Working Group Summary

As noted above, there was no response to the initial last WG on this
document.  There was good response and consensus during the second WG
last call.

  - Protocol Quality

This specification is a simple extension of the Vendor Identifying
Vendor Option defined in RFC 3925. We have no information about
current or planned implementations.  Vendors in the dhc WG expressed
support that the new sub-option would be generally useful.
2005-05-05
00 Margaret Cullen Placed on agenda for telechat - 2005-05-12 by Margaret Wasserman
2005-04-25
00 (System) State has been changed to Waiting for Writeup from In Last Call by system
2005-04-19
00 Michelle Cotton
IANA Last Call Comments:
Upon approval of this document the IANA will assign a suboption number for the
Vendor-Specific Information Suboption from the DHCP Relay …
IANA Last Call Comments:
Upon approval of this document the IANA will assign a suboption number for the
Vendor-Specific Information Suboption from the DHCP Relay Agent Information suboption number space. 
Please confirm that the registry that the IANA Considerations section is referring to is the "DHCP Agent Sub-Option Codes  per [RFC3046]" registry found at the following:
If this is not correct, please indicate which registry is correct.
2005-04-11
00 Amy Vezza Last call sent
2005-04-11
00 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-04-09
00 Margaret Cullen State Changes to Last Call Requested from Publication Requested by Margaret Wasserman
2005-04-09
00 Margaret Cullen Last Call was requested by Margaret Wasserman
2005-04-09
00 (System) Ballot writeup text was added
2005-04-09
00 (System) Last call text was added
2005-04-09
00 (System) Ballot approval text was added
2005-02-23
00 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2004-09-10
00 (System) New version available: draft-ietf-dhc-vendor-suboption-00.txt