Re: [dhcwg] IETF-93 Follow Up - draft-ietf-dhc-stable-privacy-addresses (Respond by Aug 11, 2015)

Linhui Sun <lh.sunlinh@gmail.com> Mon, 10 August 2015 08:15 UTC

Return-Path: <lh.sunlinh@gmail.com>
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 878321B331F for <dhcwg@ietfa.amsl.com>; Mon, 10 Aug 2015 01:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.082
X-Spam-Level:
X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
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 flXeL66uEInC for <dhcwg@ietfa.amsl.com>; Mon, 10 Aug 2015 01:15:31 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516501B3313 for <dhcwg@ietf.org>; Mon, 10 Aug 2015 01:15:31 -0700 (PDT)
Received: by pawu10 with SMTP id u10so135241164paw.1 for <dhcwg@ietf.org>; Mon, 10 Aug 2015 01:15:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:references:subject:mime-version :content-type:content-transfer-encoding:content-disposition; bh=6Podis2dlo/PJ22ZK7eN8BFqwii2nkphsDIhL9bFsJU=; b=NVjRN/nlHR5+FILWDPQx9Oq8OA7/NWNw52inFD2sL2TARnIHLBRS/wHTTvS5iHQlL3 W4gf4OgpdK703cxpb2nVN9OHiiNLpmZPC69posPBFZn9sSh/qDltcteZ41qv738pMgYI Sh/pgc05crbojDYUpOB1TpUDmNeG76NzCKlCS0jNNHjl8cjPGVf2cnB8Bt0DqH5TUfZu MlVSPGmE2Hw8L60VTZlzy7KhIxD64tcWKdyeIFpr3O95QhQNuhmRMv7LuxNMgPwXmpBF 2cphk1xdUuaBMlDxIjgtz4JEd0EP+ofj1ZQEwuQvn2bOv4WmOplxDi5sds16maNo4WBS fIug==
X-Received: by 10.66.141.74 with SMTP id rm10mr41791932pab.56.1439194530994; Mon, 10 Aug 2015 01:15:30 -0700 (PDT)
Received: from [127.0.0.1] ([119.28.3.169]) by smtp.gmail.com with ESMTPSA id j5sm18952828pdi.7.2015.08.10.01.15.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 01:15:29 -0700 (PDT)
Message-ID: <55c85da1.8520460a.54bd4.18c0@mx.google.com>
X-Google-Original-Message-ID: <emc_aa904171562d4232b196e61e0c13f506>
Date: Mon, 10 Aug 2015 16:15:25 +0800
From: Linhui Sun <lh.sunlinh@gmail.com>
To: dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E1CB90384@xmb-rcd-x04.cisco.com>
X-Mailer: YoMail.Win
X-YoMail-GUID: emc_aa904171562d4232b196e61e0c13f506
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/3MGY84aX3VxTA8wMRILNVSM-w2c>
Subject: Re: [dhcwg] IETF-93 Follow Up - draft-ietf-dhc-stable-privacy-addresses (Respond by Aug 11, 2015)
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 10 Aug 2015 08:15:32 -0000

Hi all,

Sorry for the late response. Have a brief look at this document, it defines an algorithm to solve the safety problem brought by IPv6 SLAAC, where the MAC address is encapsulated in the IPv6 address. I think it is useful to have a document specifying the algorithm, as it is something that the implementors could choose depending on their need. I do agree that the document need some improvements, but there are use cases where this allocation strategy is useful. I think more considerations should be taken before dropping this work completely. If the final result is not to drop it, it would be more reasonable that the document should be continued as an informational document.

Best regards,
Linhui

< Bernie Volz (volz)> 2015-07-30 01:25:42 wrote:

Hi:

 

At the DHC WG session at IETF-93 (Prague), we had a discussion about next steps for draft-ietf-dhc-stable-privacy-addresses. In particular, I (Bernie Volz) proposed we consider it a “dead WG” document (or possibly continue it as Informational). The consensus (hum) in the room was as follows:

-         Most felt (loudest hum) we should consider it a “dead WG” document.

-         A few (minor hum) were in favor of continuing work on it as an Information draft.

-         None (silent) were in favor of continuing work as is (standards track).

I had also asked this question to the mailing list a while back, and there was some discussion though no conclusive action as only a few people voiced an opinion.

 

While we don’t yet have official minutes for the meeting, you can view the Etherpad notes and audio track by visiting https://tools.ietf.org/agenda/93/" rel="nofollow">https://tools.ietf.org/agenda/93/" rel="nofollow">https://tools.ietf.org/agenda/93/" rel="nofollow">https://tools.ietf.org/agenda/93/ and scrolling down to the DHC session (on Thursday afternoon) and clicking the appropriate links.

 

The WG chairs are required to confirm any consensus obtained from a session on the WG mailing list and that is the purpose of this email.

 

Thus, if you do NOT agree with the intended action to mark the document as “dead”, please indicate so and specify why you feel this document is needed and whether to continue as Standards Track or Informational. Please respond on or before August 11th, 2015.

 

Thanks!

 

-         Bernie (& Tomek)