Re: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31

<Olaf.Bonness@telekom.de> Fri, 31 January 2014 14:17 UTC

Return-Path: <Olaf.Bonness@telekom.de>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AD91A0280 for <dhcwg@ietfa.amsl.com>; Fri, 31 Jan 2014 06:17:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level:
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHV1EDpJIPUu for <dhcwg@ietfa.amsl.com>; Fri, 31 Jan 2014 06:17:38 -0800 (PST)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 497361A0270 for <dhcwg@ietf.org>; Fri, 31 Jan 2014 06:17:37 -0800 (PST)
Received: from he113598.emea1.cds.t-internal.com ([10.125.65.117]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 31 Jan 2014 15:17:33 +0100
Received: from HE113605.emea1.cds.t-internal.com ([169.254.1.99]) by HE113598.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 31 Jan 2014 15:17:32 +0100
From: Olaf.Bonness@telekom.de
To: dhcwg@ietf.org
Date: Fri, 31 Jan 2014 15:17:32 +0100
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31
Thread-Index: Ac8ejo//m6w88ebuRjWhRwuEseOkGAAAFwcg
Message-ID: <FFD91DE61362694C94B174BB03CFDCDDF699211DAC@HE113605.emea1.cds.t-internal.com>
References: <52D87808.8040107@gmail.com> <52D9A59D.4080100@gmail.com> <9CA18722-D532-47DF-A88E-496ABF41E1A8@gmail.com> <CAF+sHxExwybpj1y9_VdkRajLr9iVJzwTiJxNvay3w+5zH2GAhQ@mail.gmail.com>
In-Reply-To: <CAF+sHxExwybpj1y9_VdkRajLr9iVJzwTiJxNvay3w+5zH2GAhQ@mail.gmail.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_FFD91DE61362694C94B174BB03CFDCDDF699211DACHE113605emea1_"
MIME-Version: 1.0
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 31 Jan 2014 14:17:42 -0000

I support forwarding this doc.

Olaf

On 2014-1-18, at 5:50, Tomek Mrugalski wrote:

> Folks,
>
> Authors and chairs feel that draft-ietf-dhc-v4configuration-04
> (http://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration/) is
> ready for WGLC. Please post your comment by end of January.
>
> If you support this draft moving forward, please say so. If you object
> this draft moving forward, please explain your concerns. Please limit
> your posts to technical comments and skip your personal preferences. "I
> like the other solution better" is not a technical comment.
>
> Please note that:
> - Softwires WG is expecting an answer from DHC WG on how to configure
> IPv4 devices in IPv6-only networks. We should answer that question.
>
> - There is a temptation to sneak in certain A+P pieces here. We must not
> do that. This is related, but a different problem. Let's solve one issue
> at a time.
>
> - -04 features an update that is a result of some off the list
> discussions. In essence, the addition is "if possible, use native DHCPv4
> without modifications. If not, here's what DHC recommends:
> DHCPv4-over-DHCPv6".
>
> With my DHC chair hat off, I'd like to ask you to do your best to not
> reopen the discussion of solution X being marginally better over Y in
> scenario Z. Yes, we can keep coming up with new metrics that would prove
> whatever metric inventor wants to prove. But that will lead us nowhere.
> There is probably no single solution that will be the best in every
> possible deployment scenario. We discussed that for over a year (much
> more if you take into account Softwire discussions). It's a high time to
> wrap things up here and move on.
>
> Bernie & Tomek
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org<mailto:dhcwg@ietf.org>
> https://www.ietf.org/mailman/listinfo/dhcwg