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

Timothy Winters <twinters@iol.unh.edu> Tue, 27 August 2013 13:03 UTC

Return-Path: <twinters@iol.unh.edu>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8795011E8323 for <dhcwg@ietfa.amsl.com>; Tue, 27 Aug 2013 06:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id razTC+gXr0K5 for <dhcwg@ietfa.amsl.com>; Tue, 27 Aug 2013 06:03:23 -0700 (PDT)
Received: from exprod5og106.obsmtp.com (exprod5og106.obsmtp.com [64.18.0.182]) by ietfa.amsl.com (Postfix) with SMTP id 9404B11E8327 for <dhcwg@ietf.org>; Tue, 27 Aug 2013 06:03:22 -0700 (PDT)
Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob106.postini.com ([64.18.4.12]) with SMTP ID DSNKUhyjl+vXorLpmO/d7M+tVqLLQ760Q0xZ@postini.com; Tue, 27 Aug 2013 06:03:23 PDT
Received: from openvpn-client17.iol.unh.edu (openvpn-client17.iol.unh.edu [132.177.124.247]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (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 <twinters@iol.unh.edu>
In-Reply-To: <5AB925D5-1B43-4D70-B859-03E331D84539@iol.unh.edu>
Date: Tue, 27 Aug 2013 09:03:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <88AB5C97-CB8A-4DB1-B32C-C15A5A2C8D68@iol.unh.edu>
References: <CE3B993C.1C26D%jason.weil@twcable.com> <5AB925D5-1B43-4D70-B859-03E331D84539@iol.unh.edu>
To: "Weil, Jason" <jason.weil@twcable.com>
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Bernie Volz <volz@cisco.com>
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS??????
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 13:03:28 -0000

Hello,
	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" 

Regards,
Tim

On Aug 27, 2013, at 8:31 AM, Timothy Winters <twinters@iol.unh.edu> 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" <jason.weil@twcable.com> 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" <otroan@employees.org> 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 [mailto:tomasz.mrugalski@gmail.com]
>>>> Sent: Monday, August 19, 2013 2:52 PM
>>>> To: dhcwg@ietf.org
>>>> 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
>>>> dhcwg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>> 
>> 
>> 
>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg