Re: [dna] Review of draft-ietf-dna-simple-11

"Bernard Aboba" <> Tue, 24 November 2009 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 713A43A68B7 for <>; Tue, 24 Nov 2009 10:23:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.655
X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0g68KRlr-OJj for <>; Tue, 24 Nov 2009 10:23:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9B4783A6820 for <>; Tue, 24 Nov 2009 10:23:20 -0800 (PST)
Received: from BLU137-DS3 ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 10:23:16 -0800
X-Originating-IP: []
X-Originating-Email: []
Message-ID: <BLU137-DS306C97D98B164596620D8939D0@phx.gbl>
From: "Bernard Aboba" <>
To: "'Ted Lemon'" <>, <>
References: <>
In-Reply-To: <>
Date: Tue, 24 Nov 2009 10:23:29 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcptLuTq2KBG1odbSZW5OOLQvFqBIQABAwOQ
Content-Language: en-us
X-OriginalArrivalTime: 24 Nov 2009 18:23:16.0168 (UTC) FILETIME=[30B92480:01CA6D33]
Subject: Re: [dna] Review of draft-ietf-dna-simple-11
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2009 18:23:21 -0000

Ted Lemon said:

"In section 4.6, the draft seems to be saying that the DHCPv6 client
should starty soliciting before it receives an RA.  This does actually
change the DHCPv6 state machine.  In fact, the DHCPv6 protocol has a
specific message for checking in the event of a DNA event: the Confirm
message.  I think Ralph already brought this up; I mention it because
it appears to be a problem to me as well.

I also think that this section goes into a lot of extra detail that is
unnecessary and probably harmful to interoperability, since what it
says doesn't really match what RFC3315 says.  It would be better to
just refer to RFC3315 here."

[BA] I agree.  Elsewhere the document states that it does not modify
DHCPv6, but the draft is sprinkled with instances where it does in
fact do this.  As far as I can tell, none of these changes add value
and so they should be replaced by a reference to RFC 3315.