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

Timothy Winters <> Tue, 27 August 2013 13:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8795011E8323 for <>; Tue, 27 Aug 2013 06:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id razTC+gXr0K5 for <>; Tue, 27 Aug 2013 06:03:23 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 9404B11E8327 for <>; Tue, 27 Aug 2013 06:03:22 -0700 (PDT)
Received: from ([]) by ([]) with SMTP ID DSNKUhyjl+vXorLpmO/; Tue, 27 Aug 2013 06:03:23 PDT
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id BBF328F007F; Tue, 27 Aug 2013 09:03:18 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Timothy Winters <>
In-Reply-To: <>
Date: Tue, 27 Aug 2013 09:03:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Weil, Jason" <>
X-Mailer: Apple Mail (2.1508)
Cc: "" <>, Bernie Volz <>
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: Tue, 27 Aug 2013 13:03:28 -0000

	Rereading my last sentence I realize that it's not very clear.  It should read the following:

	"At this point I don't think that 3315 should be advanced" 


On Aug 27, 2013, at 8:31 AM, Timothy Winters <> wrote:

> The UNH-IOL has seen several DHCPv6 Clients and DHCPv6 Server implementations struggle with the errata for allowing IA_PD to be processed when IA_NA is NotAvailable.   At this point I don't think that 3315 should not be advanced.
> Regards,
> Tim
> On Aug 22, 2013, at 10:35 AM, "Weil, Jason" <> wrote:
>> 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?
>> Jason
>> 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.
>>> cheers,
>>> Ole
>>>> -----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
>> 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.
>> _______________________________________________
>> dhcwg mailing list
> _______________________________________________
> dhcwg mailing list