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

From: "Simon Hobson" <[email-masked]>
Date: Mon, 22 Apr 2013 13:30:02 +0100

Niall O'Reilly wrote:
>	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.

I think upgrades are going to be required anyway.
But if the DUID is known, eg by being printed/barcoded on the box, then I think the intention is that you'd enter that directly into the system and bypass the need to identify the device and collect the DUID when it appears on the network.

---

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

One other implication of this is that there must be a closer connection
between the inventory system and DHCP-server(s).

This may be stepping over some departmental lines, I would not have any
clue but if so, it might have a larger significance than should be thought.

How would this work with SNMP? I am asking because I have no experience
with SNMP. I now that has been used at least some places in parallel to
both the inventory system and DHCP. Sorry if this is too much OT.

On 22/04/13 14:30, Simon Hobson 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: "Niall O'Reilly" <[email-masked]>
Date: Mon, 22 Apr 2013 14:35:35 +0100

> I think upgrades are going to be required anyway.

	No doubt.

> But if the DUID is known, eg by being printed/barcoded on the box, then I think the intention is that you'd enter that directly into the system and bypass the need to identify the device and collec…

	This is a gaping non-sequitur.

	It's not because the DUID can be read on the outside of the box
	that the system can accept the data.

	Perhaps I ought to have put BEFORE in capitals.

	I'ld suggest changing the text in the following way:

/If the DUID is known, the link-layer address MUST be ignored./s/known/known and can be accommodated by the inventory system/

	Best regards,
	Niall O'Reilly

---

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

> But if the DUID is known, eg by being printed/barcoded on the box, then I think the intention is that you'd enter that directly into the system and bypass the need to identify the device and collec…

Yup, that would eliminate the need for all this complexity.

---

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

On Apr 22, 2013, at 8:36 AM, Sten Carlsen <[email-masked]<mailto:[email-masked]>> wrote:
This may be stepping over some departmental lines, I would not have any clue but if so, it might have a larger significance than should be thought.

This draft is intended to illustrate how something can be done, not mandate that it be done, so I think we don't need to worry about this.

How would this work with SNMP? I am asking because I have no experience with SNMP. I now that has been used at least some places in parallel to both the inventory system and DHCP. Sorry if this is too much OT.

I think SNMP is indeed out of scope.  We don't have an SNMP MIB for DHCP anyway, although there are lots of private MIBs floating around out there.   My intention in this draft was to separate out the database functionality from the DHCP server, so that we didn't have to change the DHCP standard.   If it weren't for the update to RFC3315, this would be either BCP or Informational.

---

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

> /If the DUID is known, the link-layer address MUST be ignored./s/known/known and can be accommodated by the inventory system/

If it can't be accommodated by the inventory system, you aren't implementing the mechanism described in this document.   No harm, no foul.   This document just describes a way of solving the problem—if you prefer a different solution, you are not required to implement this one.

---

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

> If it can't be accommodated by the inventory system, you aren't implementing the mechanism described in this document.   No harm, no foul.   This document just describes a way of solving the proble…

	OK.  Some explicit scoping (rather than just the title) might enhance readability.

	ATB
	Niall O'Reilly

---

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

On 22/04/13 15:53, Ted Lemon wrote:
>> This may be stepping over some departmental lines, I would not have
>> any clue but if so, it might have a larger significance than should
>> be thought.
>
> This draft is intended to illustrate how something can be done, not
> mandate that it be done, so I think we don't need to worry about this.
>
If in most cases it is very impractical, maybe we should think if there
was a different way? I am just trying to be the devil's advocate here
but clearly understand that it is "a" method, not "the" method.
>>
>
> I think SNMP is indeed out of scope.
Fair enough.

-- 
Best regards

Sten Carlsen

---

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

> 	OK.  Some explicit scoping (rather than just the title) might enhance readability.

Good suggestion—thanks!

---

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

On Apr 22, 2013, at 11:52 AM, Sten Carlsen <[email-masked]<mailto:[email-masked]>> wrote:
If in most cases it is very impractical, maybe we should think if there was a different way? I am just trying to be the devil's advocate here but clearly understand that it is "a" method, not "the" method.

I don't think it is impractical; we've heard from some folks who don't want to implement it, but it's really just describing the mapping technique we talked about on the mailing list for using the client link-layer address option or the DUID.   That seemed to have a lot of support, so I don't think what's documented here is impractical; indeed, I'm quite certain it would work well.   It's probably true that it won't work for everyone, but that's probably more because they already have a different solution in place than that this solution wouldn't be a valid way to address their use case.

I get the sense that some people are still stuck on the "I don't want to support DUID at all" idea.   I don't think that's practical; my expectation is that they will eventually cave and do something like what's documented in this draft.   But that's entirely their choice, and if they come up with something that works for them, I have no quarrel at all with that.   It will probably break the protocol, though, so the IETF shouldn't be recommending it.

---

From: Sten Carlsen <[email-masked]>
Date: Mon, 22 Apr 2013 19:15:53 +0200

On 22/04/13 18:08, Ted Lemon wrote:
>> If in most cases it is very impractical, maybe we should think if
>> there was a different way? I am just trying to be the devil's
>> advocate here but clearly understand that it is "a" method, not "the"
>> method.
>
> I don't think it is impractical; we've heard from some folks who don't
> want to implement it, but it's really just describing the mapping
> technique we talked about on the mailing list for using the client
> link-layer address option or the DUID.   That seemed to have a lot of
> support, so I don't think what's documented here is impractical;
> indeed, I'm quite certain it would work well.   It's probably true
> that it won't work for everyone, but that's probably more because they
> already have a different solution in place than that this solution
> wouldn't be a valid way to address their use case.
I was thinking of impractical in the sense of administrative /
management routines that exist in companies. If too many have issues
there, I will still think the solution is impractical. I don't doubt its
technical practicality.
>
> I get the sense that some people are still stuck on the "I don't want
> to support DUID at all" idea.   I don't think that's practical; my
> expectation is that they will eventually cave and do something like
> what's documented in this draft.   But that's entirely their choice,
> and if they come up with something that works for them, I have no
> quarrel at all with that.   It will probably break the protocol,
> though, so the IETF shouldn't be recommending it.
The way I read the discussions, most people have accepted that DUID is
what you have to use whether you like it or not. At this time I expect
that the discussion is more like: How little can we change in our
routines and still make this work? I am afraid there is a tendency to
underestimate the effort needed to change administrative routines as
well as the amount of people that will have to be involved to get it done.

-- 
Best regards

Sten Carlsen