Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Mar 2016 11:19:08 +1300

Firstly, I still think this document is valuable (some comments on why I think
that are below).

Secondly, I think that Fernando, Lorenzo and Jinmei-san have raised valid
technical comments that need to be fixed. So we aren't done yet.

More in line below:

On 25/02/2016 21:04, Lorenzo Colitti wrote:
> On Thu, Feb 25, 2016 at 4:57 PM, Fernando Gont <[email-masked]>
> wrote:
> 
>>> So starting DHCPv6 without an RA is pointless because even if you get an
>>> address, you can't use to talk to anything.
>>
>> Yes, we should close that gap. Sad that a religious war essentially ends
>> up with *two* mandatory protocols. Because in many scenarios, you need
>> both.
>>
> 
> Well, that's not something we can do in this WG.

No. But IMHO it is important to document the result for hundreds of thousands
of site operators, especially the potential for divergent behaviour.

>>> 3. Where the draft says "It could be reasonably deduced that M flag
>>> should be independent from A flag" - again, the text should mention that
>>> for a client following draft-ietf-dhc-anonymity-profile, that's not true.
>>
>> Which again brings the question of why such document is not updating the
>> corresponding spec.
>>
> 
> I think you'll have to take that up with the IESG at this point. Obviously
> they took the position that doing so was not necessary; I suspect that
> position is far from conteroversial.

Exactly, or we wouldn't need this draft in the first place. As with other
IETF goofs, it's more constructive to document the problem than to ignore it.
Actually attempting to fix the specifications would be a follow-on task.

>>> 7. The draft makes no mention of Android. Perhaps it should say that
>>> Android does not have this problem because it does not implement DHCPv6?
>>
>> That's kind of misleading ;-).  That could be read to mean that it's
>> actually a good thing that android does not support ipv6.

I think Fernando meant DHCPv6 there...

>> (FWIW, Nodes that don't do v6 don't have this problem, either.)
>>
> 
> We can say whatever we can get WG consensus on, but I think we have to say
> something about Android, because there are more Android devices than most
> of the platforms that you do say something about.

Send text?

On 27/02/2016 11:18, 神明達哉 wrote:
...
> If we keep this appendix,
> I'd strongly suggest including at least one open-source BSD variant.

That would be good, but I think it's important to write at the beginning
that the tests and observations only involved a small number of stacks
and that probably not all divergent behaviours have been discovered.

Regards
    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 2 Mar 2016 09:13:16 +0000

Hi Brian,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: Wednesday, March 02, 2016 6:19 AM
> To: Lorenzo Colitti; Fernando Gont
> Cc: [email-masked] WG
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> 

[Bing] Yes, I did see some good discussion around Lorenzo's technical comments. I'll try to capture it in the next version.

> >>> So starting DHCPv6 without an RA is pointless because even if you
> >>> get an address, you can't use to talk to anything.
> >>
> >> Yes, we should close that gap. Sad that a religious war essentially
> >> ends up with *two* mandatory protocols. Because in many scenarios,
> >> you need both.
> >>
> >
> No. But IMHO it is important to document the result for hundreds of
> thousands of site operators, especially the potential for divergent behaviour.
> 
> >>> should be independent from A flag" - again, the text should mention
> >>> that for a client following draft-ietf-dhc-anonymity-profile, that's not
> true.
> >>
> >> Which again brings the question of why such document is not updating
> >> the corresponding spec.
> >>
> >
> > I think you'll have to take that up with the IESG at this point.
> > Obviously they took the position that doing so was not necessary; I
> > suspect that position is far from conteroversial.
> 
> Exactly, or we wouldn't need this draft in the first place. As with other IETF
> goofs, it's more constructive to document the problem than to ignore it.
> > We can say whatever we can get WG consensus on, but I think we have to
> > say something about Android, because there are more Android devices
> > than most of the platforms that you do say something about.
> 
> Send text?
> 
> That would be good, but I think it's important to write at the beginning that
> the tests and observations only involved a small number of stacks and that
> probably not all divergent behaviours have been discovered.

[Bing] Exactly. I think the test cases mostly serve as "hints" of possible divergence, rather than a full enumeration.

Thanks for the comments.

Best regards,
Bing 

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

---

From: 神明達哉 <[email-masked]>
Date: Wed, 2 Mar 2016 11:05:40 -0800

At Wed, 2 Mar 2016 11:19:08 +1300,

> and that probably not all divergent behaviours have been discovered.

In case my point wasn't taken as I intended: I didn't make this suggestion
to list *all divergent behaviours*; it's an impossible goal.

I suggested this because in its current content the number of tested
stacks is *too small*, especially in that there's essentially only one
100% open-source instance: Linux (of different distributions).  I
believe including open-source implementations in this type of data is
particularly important since anyone can reproduce the test scenario
more easily and can identify whether it's actually a stupid
implementation defect or it's more likely a result of protocol spec
ambiguity.  And if we know at least more than one totally different
implementations show odd behavior, it should suggest the existence of
a more general problem in the specification.

In that sense, it seems to be a very poor choice to simply use the
same OS.  It's also not very clear to me how/whether the choice of
different distributions and slightly different kernel versions
matters.

This point is also related to my other higher-level comment on the
appendices (I think Fernando made basically the same point): it's
currently presented in a very unorganized way and it's very painful to
read.  It's not immediately clear whether different
distributions/kernel versions were chosen to highlight some particular
difference between the versions/distributions, or were simply chosen
randomly available for the tester at the time of the test.  Sometimes
it may be useful to show that a particular odd behavior doesn't change
in multiple different versions, but it's also not clear from the
current presentation whether it tries to highlight that kind of point.

If this is a personal technical blog or something, it may be okay.
But it's not acceptable to me as a professional technical document
such as an RFC.

--
JINMEI, Tatuya