The DHCPv4 Relay Agent Identifier Sub-Option
draft-ietf-dhc-relay-id-suboption-13

[Ballot comment]
With the new text this is much improved and than you for the work.

I would however suggest that you do an RFC2119 scrub on the new text. For example

"Administrators should take special care to ensure that relay-ids configured in their relay agents are not duplicated."

That really should be "Administrators MUST....

Similarly in the Factory Floor case

"In deployment scenarios like this one, administrators must use some dependable technique to ensure that such misconfigurations do not occur."

That surely needs to be "MUST use"

[Ballot comment]
I support Stewart's DISCUSS regarding the uniqueness.

Note: http://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis/ updates the ENTITY-MIB RFC4133 with a ready-only UUID OID - entPhysicalUUID. This might be handy for the uniqueness discussion. In terms of draft status, the write-up has just been submitted.

Regards, Benoit;

[Ballot comment]
I have no objection to the publication of this document as an RFC, but
I have some thoughts about ID uniqueness that I hope you will consider.
These thoughts amount to support for Stewart's Discuss.

---

I think you could enhance your document by discussing the uniqueness of
the identifier more. While it is fine to require the operator to ensure
uniqueness, I think some people may have fat fingers. That means that
you should add a discussion of what happens if two relay agents show up
with the same ID: can agents or servers detect it and report it? what
might go wrong?

I also wondered what the scope of an "administrative domain" really is?

Furthermore, I wondered why we need yet another unique identifier. Can't
the relay agent re-use an existing identifier or set of identifiers that
are already guarateed to be unique-or-detectably-non-unique?

Lastly, there seems to be an understated requirement for configuration
of the ID. You give the reasoning as allowing substitution (which is a
fine reason), but it seems to me that the stronge reason is ensuring
uniqueness.

---

Your document should refer to itself (e.g. in the Abstract) as a
document or memo. An RFC that refers to itself as a draft would be
confusing.

[Ballot discuss]

This is an easy one really, even if it doesn't look like
it:-) A quick response should be all that's needed to
clear it up.

The security considerations section says that relay agents
"SHOULD use" 4030 authentication.  That's not so clear in a
few ways, so I have some questions that might help clarify
it:

- Is 4030 really used or going to be used? Other DHCP
security mechanisms are mythical, but relay/server security
should be much more tractable than anything involving the
client. (I'd like to base the resolution of the discuss more
on reality than myth;-)

- Does "SHOULD use" mean "MUST implement" or not? I think you
need to be clear.

- "SHOULD use" isn't quote clear enough - does it just apply
to messages sent out from a relay or also to messages
received, and in the latter case, where does it say what to
do if an inbound message fails verification or is that
already crystal clear?

- How does one manage keys between a relay and server?
Isn't that something where automated key managment
as discussed in BCP 107 ought be specified? Where's that
done? (Ok, that's maybe not so easy;-)

[Ballot comment]

- abstract: "a value that uniquely identifies" is the goal,
but is not guaranteed and can't be checked so I'd say "a
value that should uniquely identify" would be better. This
is a bit like Stewart's discuss.

- section 5: This seems badly phrased at least: "Implementors
should note that the identifier needs to be present in all
DHCP message types where its value is being used by the DHCP
server" as it asks for the value to be present when the value
needs to be present. I don't see how a relay implementor can
handle that statement in general.

[Ballot discuss]
Looking back over the history of this document I see a prior request to discuss the impact of non-uniqueness that has not been addressed in this revised version of the draft.

Given the nature of the deployments and the assumption of manual configuration some advice to the implementer on the consequences and precautions related to non-uniqueness is surely called for beyond the security advice to protect against malicious collision.

IANA has reviewed draft-ietf-dhc-relay-id-suboption-11 and has the following comments:

Upon approval of this document, IANA understands that a single
action needs to be completed.

IANA will make a single assignment in the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters" registry
located at:

http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

in the sub-registry "DHCP Relay Agent Sub-Option Codes" as follows:

Code: [ TBA ]
Sub-Option Description: Relay Agent Identifier Suboption
Reference: [ RFC-to-be ]

IANA understands this to be the only action required to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The DHCPv4 Relay Agent Identifier Suboption) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'The DHCPv4 Relay Agent Identifier Suboption'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This draft defines a new Relay Agent Identifier suboption for the
  Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information
  option.  The suboption carries a value that uniquely identifies the
  relay agent device within the administrative domain.  The value is
  normally administratively-configured in the relay agent.  The
  suboption allows a DHCP relay agent to include the identifier in the
  DHCP messages it sends.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-relay-id-suboption/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-relay-id-suboption/ballot/


No IPR declarations have been submitted directly on this I-D.

Previous ballot positions:


Adrian Farrel
Discuss (2009-10-20)

I would like to see some discussion of what happens if the identifier
carried in the Relay Agent Identifier suboption is not unique across
the domain. This is most likely to arise from misconfiguration of ASCII
strings (but might also happen in a security attack).

What is the impact on the network? Can one relay agent detect that there
is another operating with an identical identifier? Can other network
nodes spot the duplication? Do you expect anything more than an alert
raised by the node that spots the issue?
Comment (2009-10-20)

|Please be careful to be consistent in the name of your new sub-option.
For example, in Section 1 para 2.
  This specification introduces a Relay Agent Identifier suboption for
  the Relay Information option.  The Relay-Id suboption carries a
  sequence of octets that is intended to identify the relay agent
  uniquely within the administrative domain.

---
Notwithstanding the reference to RFC 3315, "DUID" should be expanded on
first use.
**********

Russ Housley
Discuss (2009-10-21)

  In the Gen-ART Review Sean Turner on 2009-10-06, two issues were raised.
  I have not seen a response to these issues.  The review can be found at:

  http://www.softarmor.com/rai/temp-gen-art/draft-ietf-dhc-relay-id-suboption-07-turner.txt

**********
Sean Turner

Discuss (2011-03-26)

I'm picking up Tim's discuss position.

To achieve interoperability, I believe that at least one relay identifier type
should be MUST implement.

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

Proposed Standard.  This documents an extension to the DHCPv4
protocol, so it only really makes sense as a PS.  The intended type is
indicated in the header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement
    Write-Up. Recent examples can be found in the "Action"
    announcements for approved documents. The approval announcement
    contains the following sections:

Technical Summary:

This draft defines a new Relay Agent Identifier suboption for the
Dynamic Host Configuration Protocol's (DHCP) Relay Agent
Information option.  The suboption carries a value that uniquely
identifies the relay agent device within the administrative domain.

Working Group Summary:

This document went through the working group, went to last call, and
went to the IESG, but the sole active editor of the draft at the time
wound up moving to a new job function where he no longer had time to
work on the draft, so the work languished for several years.

Recently, two new editors surfaced and began updating the document.
The exact nature of the document changed somewhat, and memories have
faded, so it was felt that we should restart the process from WGLC
back through the IESG.

This draft got quite a bit of discussion and review in the working
group during 2011 and early 2012, and passed working group last call
with some minor editorial comments and no opposition.  Because of the
history of the document, there was some back-and-forth between me and
Ralph about how to proceed with the document, with a lot of dead air
in between, so unfortunately this shepherd doc is being written almost
a year after the document passed last call.

Document Quality:

I'm not aware of any existing implementations.  There is a document
(the DHCPv4 bulk leasequery document) that depends on this document.
It's pretty clear that at least Cisco will be implementing this, and
that there is demand for it from enterprises.  Incognito has also
indicated that they intend to implement.

The document contains an acknowledgements section; obviously the two
new editors are not mentioned there, but certainly deserve thanks for
having revised the document and for pushing it back through the
process to this point.

Personnel:

Ted Lemon is the document shepherd.  Ralph Droms is the responsible AD.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

I read the document thoroughly, and feel that it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No, the document has had a great deal of review.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

This is strictly a DHCP doc, and has had plenty of review from DHCP experts.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of? For example, perhaps he or she
    is uncomfortable with certain parts of the document, or has
    concerns whether there really is a need for it. In any event, if
    the WG has discussed those issues and has indicated that it still
    wishes to advance the document, detail those concerns here.

My main concern is that the document is so late, but that's not the
IESG's problem.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed. If not, explain why?

Bharat, Ramakrishna and Mark (the three authors) have said that they
not aware of any IPR.  Mark Stapp.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

No IPR disclosures have been filed.

(9) 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 working group, including but not limited to the usual suspects,
are in favor of the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

There's been no evidence of discontent about this document, at least
in any venue I follow.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

The document was originally written quite some time ago, and idnits
pops up a pre-5378 disclaimer warning.  Mark Stapp wrote the version
of the document that triggers this warning, and has indicated that he
is willing to assign copyright to the IETF.  So I think that we can
ignore this nit.

We also get a warning because the most recent version of the document
was published in July.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

The document contains nothing like this.

(13) Have all references within this document been identified as
    either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

No.  There's an informative reference to the bulk leasequery document,
which is in the RFC-EDITOR state at the moment, but all the other
references are to RFCs.

(15) Are there downward normative references references (see RFC
    3967)? If so, list these downward references to support the Area
    Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction? If the
    RFCs are not listed in the Abstract and Introduction, explain
    why, and point to the part of the document where the relationship
    of this document to the other RFCs is discussed. If this
    information is not in the document, explain why the WG considers
    it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified. Confirm
    that newly created IANA registries include a detailed
    specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and
    a reasonable name for the new registry has been suggested (see
    RFC 5226).

The IANA considerations section looks okay to me.  This document
allocates a code from an existing registry and creates no new
registries.

(18) List any new IANA registries that require Expert Review for
    future allocations. Provide any public guidance that the IESG
    would find useful in selecting the IANA Experts for these new
    registries.

None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

There are no such parts to the document.

State changed to AD is watching from AD is watching::Revised ID Needed.
Returned to dhc WG after extensive revsion.  Will go through dhc WG last call before returning to IESG.

[Ballot discuss]
In the Gen-ART Review Sean Turner on 2009-10-06, two issues were raised.
  I have not seen a response to these issues.  The review can be found at:
  http://www.softarmor.com/rai/temp-gen-art/draft-ietf-dhc-relay-id-suboption-07-turner.txt

[Ballot comment]
|Please be careful to be consistent in the name of your new sub-option.
For example, in Section 1 para 2.
  This specification introduces a Relay Agent Identifier suboption for
  the Relay Information option.  The Relay-Id suboption carries a
  sequence of octets that is intended to identify the relay agent
  uniquely within the administrative domain.

---
Notwithstanding the reference to RFC 3315, "DUID" should be expanded on
first use.

[Ballot discuss]
I would like to see some discussion of what happens if the identifier
carried in the Relay Agent Identifier suboption is not unique across
the domain. This is most likely to arise from misconfiguration of ASCII
strings (but might also happen in a security attack).

What is the impact on the network? Can one relay agent detect that there
is another operating with an identical identifier? Can other network
nodes spot the duplication? Do you expect anything more than an alert
raised by the node that spots the issue?

IANA comments:

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "DHCP Relay Agent Sub-Option Codes" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Code Sub-Option Description Reference
---- ----------------------- ------------------------------
TBD Relay Agent Identifier Suboption [RFC-dhc-relay-id-suboption-07]


Action 2:

Upon approval of this document, IANA will create the following registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Registry Name: DHCP Relay Agent Identifier Sub-Option Types
Registration Procedures: IETF Review
Initial contents of this sub-registry will be:

Type Description Reference
---- ------------------------ -------------
0 Reserved [RFC-dhc-relay-id-suboption-07]
1 RELAY_IDENTIFIER_DUID [RFC-dhc-relay-id-suboption-07]
2 RELAY_IDENTIFIER_ASCII [RFC-dhc-relay-id-suboption-07]
3-255 Available for Assignment [RFC-dhc-relay-id-suboption-07]

We understand the above to be the only IANA Actions for this document.

Submission questions for "The DHCPv4 Relay Agent Identifier Suboption"

(1.a)  Who is the Document Shepherd for this document?  Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

John Jason Brzozowski, dhc WG co-chair
I have reviewed the document and I believe it is ready for
publication.

(1.b)  Has the document had adequate review both from key WG members and from key non-WG members?  Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document has largely been reviewed by members of the dhc WG.

At this time there are no concerns about the breadth and depth of the review conducted for this document.  This document is ready for publication.

(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML?

No, the document has been thoroughly reviewed.  No additional reviews appear to be required at this time.

(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.  Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

There were minor editorial comments along with several technical comments pertaining to constructs defined and applied in the draft.  Specifically comments pertaining to the use of DUIDs, as defined by RFC3315, as the relay-id-suboption type were raised.  All comments were discussed and have since been sufficiently addressed.

I have no specific concerns about this document.  This document is ready for publication. 

To the best of my knowledge, there are no IPR disclosures on file with the IETF related to this document.

(1.e)  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?

There was good level of WG involvement in the development leading up to the final version of this document.  There was strong consensus from a number of individuals.  There were no objections in response to the WG last call.  I believe the WG as a whole understands and agrees with the document.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

No.

(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not enough; this check needs to be thorough.  Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

All idits have been satisified.  All review criteria has been met, no additional reviews are required.

(1.h)  Has the document split its references into normative and informative?  Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?  If such normative references exist, what is the strategy for their completion?  Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

The references are split into normative and informative.  There are no problematic normative references.

(1.i)  Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document?  If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified?  If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations?  Does it suggest a reasonable name for the new registry?  See [RFC2434].  If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists.  It specifies reservations that are appropriate for the clearly identified existing registries.

(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

(1.k)  The IESG approval announcement includes a Document Announcement Write-Up.  Please provide such a Document Announcement Write-Up?  Recent examples can be found in the "Action" announcements for approved documents.  The approval announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract and/or introduction of the document.  If not, this may be
an indication that there are deficiencies in the abstract or introduction.

This memo defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option.  The suboption carries a value that uniquely identifies the relay agent device.  The value may be administratively-configured or may be generated by the relay agent.  The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends.

Working Group Summary
Was there anything in WG process that is worth noting?  For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

There was nothing controversial about this document.

Document Quality
Are there existing implementations of the protocol?  Have a significant number of vendors indicated their plan to implement the specification?  Are there any reviewers that merit special mention as having done a thorough review,  e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?  If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?  In the case of a Media Type review, on what date was the request posted?

There are currently no known server or relay implementations of this draft.  It is assumed that at least one server/relay vendor will implement this draft.  Dates for availability are not known.

Beyond what was performed with key members of the dhc WG no special reviews were performed or required.

Personnel
Who is the Document Shepherd for this document?
Who is the Responsible Area Director?
Is an IANA expert needed?

Shepherd: John Jason Brzozowski
AD:      Ralph Droms
IANA:    N/A