Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS??????

Ole Troan <> Thu, 22 August 2013 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6934E21F9E9C for <>; Thu, 22 Aug 2013 06:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JrTRisKdCrRd for <>; Thu, 22 Aug 2013 06:39:35 -0700 (PDT)
Received: from ( [IPv6:2001:1868:205::19]) by (Postfix) with ESMTP id 8F78521F9DF6 for <>; Thu, 22 Aug 2013 06:39:35 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id 7193B5ED9; Thu, 22 Aug 2013 06:39:32 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_366B64F0-1389-40E2-BBE6-57E473DF8B58"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ole Troan <>
In-Reply-To: <>
Date: Thu, 22 Aug 2013 15:39:29 +0200
Message-Id: <>
References: <>
To: Bernie Volz (volz) <>
X-Mailer: Apple Mail (2.1508)
Cc: "" <>
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS??????
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Aug 2013 13:39:36 -0000

> Unless we receive some additional comments from the WG, we will be forced to conclude that there is NO support for advancing these documents to Internet Standard.
> Because of the time of year (perhaps the last of summer vacations), we will wait until September 9th to make a final decision. But at the current rate of response, it does not look favorable.

I do not support advancing RFC3315/RFC3633 to Internet Standard.
reason being that I believe that there are errata that will lead to interoperability problems.


> -----Original Message-----
> From: Tomek Mrugalski [] 
> Sent: Monday, August 19, 2013 2:52 PM
> To:
> Cc: Bernie Volz (volz)
> Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard
> On 12.08.2013 21:21, Bernie Volz (volz) wrote:
>> During the Berlin IETF-87 DHC WG session, it was suggested that we 
>> initiate a standards action request to move RFC 3315 (and RFC 3633), 
>> which are presently Proposed Standards, to Internet Standard. While we 
>> plan to work on a 3315bis which would merge the work, it was pointed 
>> out by several people (include our Area Director) that there is 
>> technically no need to wait for that to advance the standards.
>> The requirements for advancement are outlined in RFC 2026 and RFC 6410 
>> (which removed Draft Standard).
>> Per RFC 6410:
>> The criteria are:
>>   (1) There are at least two independent interoperating implementations
>>       with widespread deployment and successful operational experience.
> There are many more than just two.
>>   (2) There are no errata against the specification that would cause a
>>       new implementation to fail to interoperate with deployed ones.
> There are known issues, e.g. those described in draft-ietf-dhc-dhcpv6-stateful-issues, but these are more of annoyance, rather than interoperability breaking problems. New implementations are interoperating with existing ones without problems.
>>   (3) There are no unused features in the specification that greatly
>>       increase implementation complexity.
> That's an interesting question. Are there any implementations that implement the whole RFC3315? I mean really everything: reconfiguration, reconfigure-key, delayed auth, replay detection, sending CONFIRM when link state changes, sending DECLINE if DAD fails, rapid-commit, supporting 32 relays, all 3 duid types etc.?
> That's a trick question. I have my own answer for it, but I'd like to hear WG opinion on that matter.
>>   (4) If the technology required to implement the specification
>>       requires patented or otherwise controlled technology, then the
>>       set of implementations must demonstrate at least two independent,
>>       separate and successful uses of the licensing process.
> There are no IPRs claimed against RFC3315 and RFC3633.
> Ok, so in my opinion all criteria are met.
>> Please provide input as to whether you support making this request of 
>> the IETF/IESG (via the Internet Area Directors) or whether you feel 
>> there are issues (based on the above criteria). If you feel one 
>> document is ready but the other isn't, please let us know about that too.
> I feel that we should move forward with this for both 3315 and 3633.
> There's almost 7000 RFCs published, but there are only 96 that have Internet Standard status. I strongly believe that DHCPv6 is one of core Internet protocols. This status change would reflect that.
> With my chair on, I'm disappointed that nobody responded to this mail so far. Chairs got couple comments off the list, but nobody said anything on the list. I don't know, perhaps people are not that much interested, because this move does not have any immediate practical repercussions.
> Or perhaps it is a middle of vacation time...
> Come on, guys. Saying +1 doesn't take much time. ;-)
> Tomek
> _______________________________________________
> dhcwg mailing list