Subject: [mif] #16: DHCPv6 route option does not belong in MIF working group

From: "mif issue tracker" <[email-masked]>
Date: Mon, 05 Nov 2012 15:17:04 -0000

#16: DHCPv6 route option does not belong in MIF working group

 The DHCPv6 route option does not belong in the MIF working group.
 Rationale:

 1. Virtually all the use cases provided (as of draft-05, at least  #1, #2,
 #3, #4, #5, #7, #8, #9, #10) are not specific to hosts with multiple
 interfaces, and apply equally well to hosts with one interface.
 2. The DHCPv6 route option duplicates, in a different way, functionality
 which is part of the core protocol specification. Specifically, it
 duplicates functionality of RFC 4862 (stateless address autoconfiguration,
 routing, on-link prefixes).

 Duplicating core IPv6 protocol functionality in a different working group
 is a bad idea. Work on this option should be moved to 6man, which is
 authoritative for configuration of routing on IPv6 nodes.

-- 
-------------------------+-------------------------------------------------
 Reporter:  lorenzo@…    |      Owner:  draft-ietf-mif-dhcpv6-route-
     Type:  defect       |  option@…
 Priority:  blocker      |     Status:  new
Component:  dhcpv6       |  Milestone:
  -route-option          |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/mif/trac/ticket/16>
mif <http://tools.ietf.org/mif/>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Nov 2012 15:28:14 +0000

> authoritative for configuration of routing on IPv6 nodes.

The MIF working group has in its charter an action item to do a DHCPv6 route option.   You've admitted that there are use cases that are motivated by the multiple interface use case.   The existence of use cases without that motivation therefore doesn't seem to be a valid argument for your assertion that this should be done in a different working group.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Nov 2012 15:43:07 +0000

On 05/11/2012 15:28, Ted Lemon wrote:
> The MIF working group has in its charter an action item to do a DHCPv6 route option.

Charters can be changed.

> You've admitted that there are use cases that are motivated by the multiple interface use case.   The existence of use cases without that motivation therefore doesn't seem to be a valid argument for your assertion that this should be done in a different working group.

I think it is, given that the option would (if defined) obviously be used
widely. At the very minimum, 6man would have to say "no objection" to this.

Regards
   Brian Carpenter
   Cell phone during IETF85: +1 847 219 0880

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2012 00:53:46 +0900

> The MIF working group has in its charter an action item to do a DHCPv6

The fact that the group was chartered to do this years ago does not mean it
is still the best place to have this discussion, or even that this is a
good idea at all. And I would argue the charter is not the right place to
specify solutions, anyway. Much better to specify problem statements and
areas to work on, not solutions. The solution space should be left to the
WG - because you don't know, before you actually explore the solution
space, whether a specific solution is a good idea.

  You've admitted that there are use cases that are motivated by the
> multiple interface use case.

The only use cases I see where multiple interfaces are relevant *at all*
are #6 and #8 (though these use cases can be relevant on single interfaces
as well). All the others apply identically to hosts with only one
interface. I don't think saying "2 out of 11 use cases are partially
relevant to hosts with multiple interfaces" is a justification for having
this draft be in MIF instead of in 6man, especially since it duplicates
core protocol work standardized by 6man.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Nov 2012 15:56:04 +0000

> widely. At the very minimum, 6man would have to say "no objection" to this.

Currently many (perhaps most!) IPv6-capable devices don't even _implement_ DHCPv6 for IP address allocation.   So this claim is not a statement of fact—it is clearly not true.

As speculation as to what might happen in the future, it is of questionable value—we simply don't know what the future holds.   As a user of IPv6 on my home network, I don't see much use for this option, so it seems like a special case option to me.   When we met in Paris, at least one operator said that he didn't want to use this option because it would make managing his network harder (ironically, he was against the option out of a fear that he would somehow be forced to use it despite his strong preference not to do so).

I realize that you have a different opinion, but my point is that both your opinion and mine are pure speculation—there is no way to know what will actually happen if this option becomes a standard.   Consequently, the working group should take neither your speculation nor mine into account—what we should talk about is whether there are motivating use cases for this draft, and whether there are serious technical problems or known drawbacks with the draft such that, if it were to advance, something bad would definitely happen.

Of course, chances are we won't have that sort of discussion, because there are some religious folks who have strong beliefs here, but I feel obliged to mention it as an aspirational goal.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Nov 2012 16:06:12 +0000

On Nov 5, 2012, at 10:53 AM, Lorenzo Colitti <[email-masked]> wrote:
>  I don't think saying "2 out of 11 use cases are partially relevant to hosts with multiple interfaces" is a justification for having this draft be in MIF instead of in 6man, especially since it duplicates core protocol work standardized by 6man.

This is a situation where someone was asked to come up with a list of actual use cases, and misunderstood the meaning of this request, and instead speculated as to how the option could in theory be used, and came up with a long list of such speculative use cases.

As far as I know, the motivating use case for this document is in fact use case 8.   We've since heard from BBF that they have another use case, which is something like use case 7, but slightly different, in the sense that it has to do with QoS rather than IP address space segregation.   The other use cases are not actual use cases that anyone has in the real world; a number of them are contrived, and it's difficult to imagine them actually happening in the real world.

So as a criticism of the document, I think the point you are making is valid—all of the use cases that don't have actual customers should be removed from the document.   If that were to happen, then we would have one use case that's clearly a MIF-specific use case, and a second use case that's sort of relevant to MIF, but not really MIF-specific.

This would be a useful exercise, and after doing so it might be worth reconsidering the point you've made.   However, at this point I don't think your point can be realistically considered, because there is so much noise and so little signal in the section of the document on use cases.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2012 01:16:24 +0900

On Tue, Nov 6, 2012 at 1:06 AM, Ted Lemon <[email-masked]> wrote:

> So as a criticism of the document, I think the point you are making is
> valid—all of the use cases that don't have actual customers should be
> removed from the document.   If that were to happen, then we would have one
> use case that's clearly a MIF-specific use case, and a second use case
> that's sort of relevant to MIF, but not really MIF-specific.
>
> This would be a useful exercise, and after doing so it might be worth
> reconsidering the point you've made.   However, at this point I don't think
> your point can be realistically considered, because there is so much noise
> and so little signal in the section of the document on use cases.
>

Ok, so I read your paragraph as "the problem statement for this draft is
vague and unparseable". But isn't that a serious problem with the document
that needs to be addressed?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Nov 2012 16:23:36 +0000

On Nov 5, 2012, at 11:16 AM, Lorenzo Colitti <[email-masked]> wrote:
> Ok, so I read your paragraph as "the problem statement for this draft is vague and unparseable". But isn't that a serious problem with the document that needs to be addressed?

Yes, absolutely, and I communicated this to the authors when they issued the current version of the draft.   I am disappointed that this has not yet been fixed.   However, it is _not_ the problem that issue #16 talks about. :)

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 6 Nov 2012 04:16:46 +0900

In my understanding, we are now using issue tracker to fix such vagueness
and errors in problem statements.

Regarding the issue of a real problem and a contrived problem, I think the
criteria should not be "it is really happening somewhere", but be "enough
people agree to solve the problem".

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Nov 2012 19:21:35 +0000

On Nov 5, 2012, at 2:16 PM, Arifumi Matsumoto <[email-masked]>
 wrote:
> Regarding the issue of a real problem and a contrived problem, I think the criteria should not be "it is really happening somewhere", but be "enough people agree to solve the problem".

That's not a great metric, because the IETF seems to work on a lot of problems with no customers.

This document actually has several customers, so there's no reason to contrive use cases for which no customers exist.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 6 Nov 2012 04:32:28 +0900

If one customer is enough for each use case, then each of the use case in
the draft has it.
It is a different question, whether he is really facing the problem, or he
thinks he will be.

But, I think it is not the only criteria whether the WG should work on the
use case.

2012/11/6 Ted Lemon <[email-masked]>

> > Regarding the issue of a real problem and a contrived problem, I think
> the criteria should not be "it is really happening somewhere", but be
> "enough people agree to solve the problem".
>
> This document actually has several customers, so there's no reason to
> contrive use cases for which no customers exist.
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2012 06:50:56 +0900

On Tue, Nov 6, 2012 at 1:23 AM, Ted Lemon <[email-masked]> wrote:

> Yes, absolutely, and I communicated this to the authors when they issued
> the current version of the draft.   I am disappointed that this has not yet
> been fixed.   However, it is _not_ the problem that issue #16 talks about.
> :)
>

You're right. I will file another issue then.