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

Timothy Winters <> Tue, 27 August 2013 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79CED11E8302 for <>; Tue, 27 Aug 2013 05:31:47 -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 5TNwFOGhX+6k for <>; Tue, 27 Aug 2013 05:31:42 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 4B9F411E82E9 for <>; Tue, 27 Aug 2013 05:31:40 -0700 (PDT)
Received: from ([]) by ([]) with SMTP ID DSNKUhycBmW4hAus3/KTYXVu4ZUYGJc5Jg1/; Tue, 27 Aug 2013 05:31:42 PDT
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D9D218F0082; Tue, 27 Aug 2013 08:31:01 -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 08:31:02 -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 12:31:47 -0000

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.


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