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

"Weil, Jason" <> Thu, 22 August 2013 14:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12FF411E8170 for <>; Thu, 22 Aug 2013 07:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.537
X-Spam-Level: *
X-Spam-Status: No, score=1.537 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RoI38Cg9rvND for <>; Thu, 22 Aug 2013 07:35:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 55A5511E81DC for <>; Thu, 22 Aug 2013 07:35:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.89,934,1367985600"; d="scan'208";a="125250412"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 22 Aug 2013 10:34:36 -0400
Received: from ([]) by ([]) with mapi; Thu, 22 Aug 2013 10:35:02 -0400
From: "Weil, Jason" <>
To: Ole Troan <>, Bernie Volz <>
Date: Thu, 22 Aug 2013 10:35:01 -0400
Thread-Topic: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS??????
Thread-Index: Ac6fRMljYlOtFpekQheJzf46n32Qng==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 14:35:09 -0000

I am also not seeing the benefit of pushing two RFCs that are in the
process of being merged to something better than the sum of their parts
before that merge is successful. And like Ole mentioned wouldn't it fail
on the errata point (2) from Tomek's original email anyway?


On 8/22/13 9:39 AM, "Ole Troan" <> wrote:

>> 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
>> 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
>> 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
>> Or perhaps it is a middle of vacation time...
>> Come on, guys. Saying +1 doesn't take much time. ;-)
>> Tomek
>> _______________________________________________
>> dhcwg mailing list

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.