Subject: [dhcwg] draft-lemon-dhc-inventory-00

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Apr 2013 00:22:58 +0000

Regular DHC working group members may be amused or perhaps disturbed to learn that I've posted yet another ops doc for the working group.  This one documents how enterprises and ISPs can manage their network device inventory using bar codes on boxes, link-layer addresses, and DUIDs.

It might be slightly more controversial than the topology document, because it actually proposes an update to RFC3315 to clarify the meaning of the text forbidding the DHCP server looking at the contents of DUIDs.   This probably ought to be in a separate document, if the working group agrees that this is a good idea.

Like the topo doc, this is being submitted with my AD hat off—the reason I've submitted so many documents lately is because I keep noticing situations where we all know something, but nobody else in the IETF knows it, and I think it's worth actually documenting this stuff.

Let me know what you think!

Thanks!

http://tools.ietf.org/html/draft-lemon-dhc-inventory-00

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Apr 2013 00:51:30 +0000

> http://tools.ietf.org/html/draft-lemon-dhc-inventory-00

I wound up submitting a -01 because I accidentally copied the security considerations section from the topo doc and then forgot to update it.   The -01 includes a more relevant and complete security considerations section.

http://tools.ietf.org/html/draft-lemon-dhc-inventory-01

---

From: Sten Carlsen <[email-masked]>
Date: Mon, 22 Apr 2013 03:07:40 +0200

I think this is insufficient, it only covers the trivial case:

" We are assuming in this case that the link-layer address is available
to the DHCP server because it and the router are connected to the same
physical link, so the link-layer address appears in the packet header of
the received Solicit packet."

This rules out any case that involves a relay as insolvable?

The paper needs to explain how things should work in any case that can
be solved in IPv4.

On 22/04/13 2:51, Ted Lemon wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Apr 2013 01:15:43 +0000

On Apr 21, 2013, at 9:07 PM, Sten Carlsen <[email-masked]<mailto:[email-masked]>> wrote:
This rules out any case that involves a relay as insolvable?

Did you read past this point to the following sections where two strategies for dealing with cases where the client is not on the same link are discussed?   I guess I didn't make that very explicit; I can update this text to point to the later sections of the document.

---

From: Sten Carlsen <[email-masked]>
Date: Mon, 22 Apr 2013 04:02:36 +0200

I did read through the whole document but missed that case. I found the
sentence in third read through, looking for it the two last times.

I think it should be described in the same level of detail, specially it
should be described exactly which RFCs mandate the relay to forward the
link-layer address to the server. I believe that is a very well kept
secret in a narrow circuit, it is not common knowledge in the dhcp-users
maillist.

Other than that , I think it will fill a void, that many have fallen
into and will in the future.

I am sorry
On 22/04/13 3:15, Ted Lemon wrote:
> Did you read past this point to the following sections where two
> strategies for dealing with cases where the client is not on the same
> link are discussed?   I guess I didn't make that very explicit; I can
> update this text to point to the later sections of the document.
>

-- 
Best regards

Sten Carlsen

---

From: "Niall O'Reilly" <[email-masked]>
Date: Mon, 22 Apr 2013 10:39:22 +0100

On 22 Apr 2013, at 01:22, Ted Lemon wrote:

> this is being submitted with my AD hat off—the reason I've submitted so many documents lately is because I keep noticing situations where we all know something, but nobody else in the IETF knows it, and I think it's worth actually documenting this stuff.

	Absolutely.

	For me, MUST is too strong in the passage

> 2.  General Mechanism
> 
>    This mechanism takes as its input two pieces of information: one of
>    the link-layer addresses of a device, and the DUID of the device.  If
>    the DUID is known, the link-layer address MUST be ignored.  If the
>    DUID is unknown, the link-layer address is used to find the the
>    inventory record for the device, and then the the DUID is added to
>    the inventory record.

	This seems to impose a requirement for an upgrade to the
	inventory system in order to accommodate DUID before any
	device whose DUID is known can be unpacked.

	Is this the intention?

	Best regards,
	Niall O'Reilly

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Apr 2013 12:49:46 +0000

On Apr 21, 2013, at 10:02 PM, Sten Carlsen <[email-masked]<mailto:[email-masked]>> wrote:
I think it should be described in the same level of detail, specially it should be described exactly which RFCs mandate the relay to forward the link-layer address to the server. I believe that is a very well kept secret in a narrow circuit, it is not common knowledge in the dhcp-users maillist.

Okay, fair enough.   I've added this in the middle of the discussion:

        <t>
          We are assuming in this section that the link-layer address
          is available to the DHCP server because it and the router
          are connected to the same physical link, so the link-layer
          address appears in the packet header of the received Solicit
          packet.  In cases where the DHCP client is not on the same
          link as the DHCP server, the server must obtain the
          link-layer address using the techniques described in
          Sections <xref target="duid" format="counter"/> and
          <xref target="linklayer" format="counter"/>.
        </t>

I'll think about whether I can add anything, but if you have a clear idea of what to add, it might be better if you did it--I have limited time to work on this stuff, and only wrote this out because it was practically begging to pop off the tips of my fingers.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Apr 2013 13:04:05 +0000

> 	device whose DUID is known can be unpacked.

Your inventory management system doesn't have to conform to this draft.   It's just documenting a mechanism for mapping physical inventory to DHCP requests.   The reason for the MUST is that the DUID is the identifier, not the link-layer address, so once you have the DUID in the system, using the link-layer address is (a) superfluous and (b) might cause problems if it changes.

---

From: Sten Carlsen <[email-masked]>
Date: Mon, 22 Apr 2013 17:55:11 +0200

On 22/04/13 14:49, Ted Lemon wrote:
>> I think it should be described in the same level of detail, specially
>> it should be described exactly which RFCs mandate the relay to
>> forward the link-layer address to the server. I believe that is a
>> very well kept secret in a narrow circuit, it is not common knowledge
>> in the dhcp-users maillist.
>
> I'll think about whether I can add anything, but if you have a clear
> idea of what to add, it might be better if you did it--I have limited
> time to work on this stuff, and only wrote this out because it was
> practically begging to pop off the tips of my fingers.
This looks fine to me, provided the xrefs become more specific, which I
am sure will happen :-) .

-- 
Best regards

Sten Carlsen

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Apr 2013 16:09:10 +0000

On Apr 22, 2013, at 11:55 AM, Sten Carlsen <[email-masked]<mailto:[email-masked]>> wrote:
This looks fine to me, provided the xrefs become more specific, which I am sure will happen :-) .

xml2rfc should take care of that. :)