Subject: Re: [dhcwg] draft-despres-intarea-4rd comments

From: Rémi Després <[email-masked]>
Date: Fri, 1 Apr 2011 09:41:21 +0200

Hi Tomasz,

Comments in line.

Le 31 mars 2011 à 16:55, Tomasz Mrugalski a écrit :

> I have partially read the draft (mostly the parts related to DHCPv6) and
> would like to provide my comments. I may have additional comments as I
> finish proper reading throughout the draft.
> 
> First, I'm sorry if my comments may seem a bit harsh, but the currently
> proposed option format is catastrophic. It is basically several
> suboptions stuffed together with suboption-like type and length coded on
> nibbles, rather than usual 2 byte fields, with some suboptions being
> optional. These parameters should clearly be defined as separate options
> (possibly grouped together as suboptions within an option for clarity).

Thanks for expressing a view, this was the goal of this presentation.
No catastrophy ahead, there is enough time make proposal that reach consensus in the WG.

> Defined that way, it would be much easier to parse/build such options by
> involved entities. I will also be less problematic to support by
> implementations that also definition of custom options. Luckily, that
> can be fixed quite easily. Hopefully, there are no (or very limited)
> implementations, so redoing the option layout should be no problem.

No implementation I heard of includes the DHCPv6 part of the draft.

> There are no usual DHCPv6 Server or Client Behavior sections. Although
> not strictly required, they are very convienient for vendors that are
> looking for clean list of requirements that they must meet to claim spec
> conformance.
> 
> There is no mention of DHCPv6 related problems in Security
> Considerations section whatsoever. This should be analysed a bit and
> commented in the text (possibly briefly if there are no new issues here,
> with just pointers to existing RFCs).

No 4rd specific security concern about dhcpv6 ahd been identified, and RFC 5969 on 6rd has no such mention.
Yet, if you have a particular suggestion, why not?

> Also, I have a procedural recommendation. I happen to have worked on
> DHCPv6 option for another IPv4-IPv6 coexistence architecture. The actual
> architecture and the DHCPv6 operation were specified in separate, but
> closely related documents. It worked really well, because discussed
> problems and review groups are mostly orthogonal. They could also
> possibly follow separate adoption paths (or perhaps not, but that is
> something that should be possibly considered).

Doing it earlier might have been more complex than needed, but doing it for a later version does make sense to me.
A volunteer for te DHCPv6 draft will be welcome (I am clearly not an expert of this WG).

> Remi asked for DHC experts to provide help with this. I'm not sure if I
> qualify to that distinction, but I'm happily volunteering for work on
> this. I will coordinate with Remi and other authors how they would like
> to organize the work.

> Hope that helps,

IMHO, it does, thank you.

Regards,
RD

> Tomek Mrugalski
> ISC

---

From: Tomasz Mrugalski <[email-masked]>
Date: Fri, 01 Apr 2011 14:02:13 +0200

> No catastrophy ahead, there is enough time make proposal that reach consensus in the WG.
I would like to withdraw my comment and apologize for using such strong
words. What I really meant is that such complicated format may easily be
misimplemented, that could even lead to client crashes. While it has
benefits of being very compact, we have agreed that following standard
DHCPv6 format would be better way to move forward as long as all
currently defined parameters are delivered to clients.

> No 4rd specific security concern about dhcpv6 ahd been identified, and RFC 5969 on 6rd has no such mention.
Thank you for clarifying that. I'll add appropriate comment to that effect.

> A volunteer for te DHCPv6 draft will be welcome (I am clearly not an expert of this WG).
I have volunteered to be an editor of this draft and discussed this with
Remi, who accepted my proposal. If others are interested in this, please
contact Remi and myself.

Tomek Mrugalski
ISC