Subject: Re: [v6ops] I-D Action: draft-yourtchenko-ra-dhcpv6-comparison-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Dec 2013 13:49:47 +1300

Hi,

(Still on v6ops, although 6man might be appropriate.)

I think that there are some topics quite deep inside the
draft that really belong nearer the beginning. After all,
these are the issues that will guide future work: do we add
feature X to RA, DHCPv6, or both?.

In a logical order, these topics are:

a) 4. Differences between different types of network operators

b) 2.11. Scope of use / Applicability
(e.g. 2.7. Involvement or not into routing)
(e.g. to what extent do we want feature-equivalence
and a shared data model?)

c) 2.10.  Separate vs. unified management

There may be other general topics but those three stood
out for me.

Oh, and there's this:

> 2.13.  Security tools impact comparison
> 
>    From Brian Carpenter.  For further discussion.

Not quite sure what I had in mind there. What I wrote (in
off-list mail) was "There's also the question of how the
approaches relate to APAM tools and to security tools."
I can see that there might be interaction with APAM. Maybe
there needs to be interaction with address-based security
settings?

Regards
   Brian

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 17 Dec 2013 11:12:39 +0000 (WET)

Hi,

> (Still on v6ops, although 6man might be appropriate.)

yep. See my comment at the end.

> there needs to be interaction with address-based security

Hm. Not sure :-)

Anyway, the practical choice today really is one of the two:

1) RA-only
2) RA+DHCP

I think I heard fairly distinct objections against even thinking about 
touching this. Even if I also heard a distinct dissatisfaction 
with this state of affairs, unless there's a consensus to think of 
changing it, we have what we have.

Thus if we assume this status quo + the MUST / SHOULD designations in 
hosts requirements, I'd put a decision tree a potential implementer
as follows:

1) Are you configuring an application ? If yes - avoid RA and DHCP 
altogether, do something else. If you are configuring an INTAREA protocol, 
continue to (2).

2) Do you have a very very very good reason to use DHCPv6 as a carrier for 
your configuration info, even bearing in mind that not all nodes may 
support it (or the subset of nodes of interest ? Then use DHCPv6.

3) Use RA.

The draft then is indeed aiming at the protocol implementors aiming to 
answer the (2), the abstract needs to be sharpened to reflect that, and 
indeed a much better place for it would be (eventually) 6man (with the 
help of dhc, of course).

Therefore: I solicit those who are interested to further work on this 
doc to unicast me, so we can free up the carrier in v6ops.

--a

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Dec 2013 18:58:52 +0100

Le 17/12/2013 12:12, Andrew Yourtchenko a écrit :
>> I think that there are some topics quite deep inside the draft that
>> really belong nearer the beginning. After all, these are the issues
>> that will guide future work: do we add feature X to RA, DHCPv6, or
>> both?.
>>
>> b) 2.11. Scope of use / Applicability (e.g. 2.7. Involvement or not
>> into routing) (e.g. to what extent do we want feature-equivalence
>> There may be other general topics but those three stood out for
>> me.
>>
>> Oh, and there's this:
>>
>> Not quite sure what I had in mind there. What I wrote (in off-list
>> mail) was "There's also the question of how the approaches relate
>> to APAM tools and to security tools." I can see that there might be
>> interaction with APAM. Maybe there needs to be interaction with
>> address-based security settings?
>
> Hm. Not sure :-)
>
> 1) RA-only 2) RA+DHCP
> I think I heard fairly distinct objections against even thinking
> about touching this. Even if I also heard a distinct dissatisfaction
> altogether, do something else. If you are configuring an INTAREA
> protocol, continue to (2).
>
> 2) Do you have a very very very good reason to use DHCPv6 as a
> carrier for your configuration info, even bearing in mind that not
> all nodes may support it (or the subset of nodes of interest ? Then
> use DHCPv6.
>
> 3) Use RA.
>
> The draft then is indeed aiming at the protocol implementors aiming
> to answer the (2), the abstract needs to be sharpened to reflect
> that, and indeed a much better place for it would be (eventually)
> 6man (with the help of dhc, of course).
>

But in this email one seems to be suggesting a big recommendation DHCP
vs RA, whereas something smaller and less contentious would be - among
other things -  a description of parameters configured by DHCP vs
parameters configured by RA.

Alex

>
> --a _______________________________________________ v6ops mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 18 Dec 2013 13:20:23 +0000 (WET)

> parameters configured by RA.

I think that's how it started... (from my email attempting to specify the 
properties of DHCP vs. RA in order to be able to easier choose DHCP vs. 
RA). I suppose having an appendix with "what is configured today via DHCP 
and what is configured via RA" is ok.

--a

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Dec 2013 08:33:15 +1300

On 19/12/2013 02:20, Andrew Yourtchenko wrote:
> I think that's how it started... (from my email attempting to specify
> the properties of DHCP vs. RA in order to be able to easier choose DHCP
> vs. RA). I suppose having an appendix with "what is configured today via
> DHCP and what is configured via RA" is ok.

IMHO it's a lot more than OK: it would be a highly useful objective reference.

   Brian