Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)

Fernando Gont <fgont@si6networks.com> Wed, 22 January 2014 20:49 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D381A0158; Wed, 22 Jan 2014 12:49:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 AdKlDfLyf9QV; Wed, 22 Jan 2014 12:49:03 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B53121A01B3; Wed, 22 Jan 2014 12:49:03 -0800 (PST)
Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1W64jJ-0000rC-Sw; Wed, 22 Jan 2014 21:48:58 +0100
Message-ID: <52E02C0C.7080901@si6networks.com>
Date: Wed, 22 Jan 2014 17:37:32 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Pete Resnick <presnick@qti.qualcomm.com>, The IESG <iesg@ietf.org>
Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com>
In-Reply-To: <20140122192018.8692.82071.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 20:49:06 -0000

Hi, Pete,

Thanks so much for your feedback! -- Please find my responses in-line...

On 01/22/2014 04:20 PM, Pete Resnick wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This is an algorithm to generate stable, private, and mostly unique
> addresses. It does not affect interoperability at all if people choose a
> different method. 

The short answer to this is what Bob has already responding:

We currently require nodes to embed their hardware address in the IID
when they do SLAAC. And every other specification to generate IIDs is
also Std track. So we are being consistent.

In addition, the document itself has requirements when it comes to
things you MUST or SHOULD do... otherwise, the mechanism doesn't work as
expected.

All the above said, there are many documents from different areas where
we have std track RFCs which "do not affect interoperability". e.g. TCP
congestion control, TCPs initial RTO, etc. which, from your pov, should
be informational?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492