Re: Protocol Action: 'A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)' to Proposed Standard (draft-ietf-6man-stable-privacy-addresses-17.txt)

Fernando

Congratulations.

When I first saw this I-D, I thought what a sensible idea.  Since then,
I have been surprised, amazed even, at the opposition that has been put
up, on this list, on the IETF list and even by the IESG.  I have
wondered why and have no rational explanation but do believe that you
deserve a special mention for seeing this through, when others might
have given up long ago (well, I would have done:-(

So, congratulations.

Tom Petch

----- Original Message -----
From: "The IESG" <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: "6man chair" <6man-chairs@tools.ietf.org>; "6man mailing list"
<ipv6@ietf.org>; "RFC Editor" <rfc-editor@rfc-editor.org>
Sent: Thursday, January 30, 2014 11:54 PM
Subject: Protocol Action: 'A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Autoconfiguration
(SLAAC)' to Proposed Standard
(draft-ietf-6man-stable-privacy-addresses-17.txt)

> The IESG has approved the following document:
> - 'A Method for Generating Semantically Opaque Interface Identifiers
with
>    IPv6 Stateless Address Autoconfiguration (SLAAC)'
>   (draft-ietf-6man-stable-privacy-addresses-17.txt) as Proposed
Standard
>
> This document is the product of the IPv6 Maintenance Working Group.
>
> The IESG contact persons are Brian Haberman and Ted Lemon.
>
> A URL of this Internet Draft is:
>
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses
/
>
>
>
>
> Technical Summary:
>
>    This document specifies a method for generating IPv6 Interface
>    Identifiers to be used with IPv6 Stateless Address
Autoconfiguration
>    (SLAAC), such that addresses configured using this method are
stable
>    within each subnet, but the Interface Identifier changes when hosts
>    move from one network to another.  This method is meant to be an
>    alternative to generating Interface Identifiers based on hardware
>    addresses (e.g., IEEE LAN MAC addresses), such that the benefits of
>    stable addresses can be achieved without sacrificing the privacy of
>    users.  The method specified in this document applies to all
prefixes
>    a host may be employing, including link-local, global, and unique-
>    local addresses.
>
> Working Group Summary:
>
>   This document was sent back to the working group based on the number
of
>   comments received during the IETF last call.  The current document
is
>   significantly improved.   After a long discussion, another working
>   group last call was done with support from the w.g.  The chairs had
two
>   reviewers, Ray Hunter and Mark Smith, did a detailed review of the
>   draft.  This resulted in several changes in the current draft (-14).
>   The reviewers have told us that the new draft resolves the issues
they
>   raised.  The w.g. chairs believe the draft is ready to send to the
IESG
>   again.
>
>   In addition Alissa Cooper revised the document and is working on a
draft
>   that provides an overview of the privacy considerations with all
types of
>   IPv6 addresses.
>
> Document Quality:
>
>    No implementations known.
>
> Personnel:
>
>   Bob Hinden is the Document Shepherd.
>
>   Brian Haberman is the Responsible Area Director.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>