[Rtg-dt-encap-considerations] Realized we should have a change log

Erik Nordmark <nordmark@sonic.net> Wed, 20 May 2015 20:25 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: rtg-dt-encap-considerations@ietfa.amsl.com
Delivered-To: rtg-dt-encap-considerations@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CEC1A8F37 for <rtg-dt-encap-considerations@ietfa.amsl.com>; Wed, 20 May 2015 13:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level:
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 kreS71DLWArX for <rtg-dt-encap-considerations@ietfa.amsl.com>; Wed, 20 May 2015 13:25:34 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE571A9084 for <Rtg-dt-encap-considerations@ietf.org>; Wed, 20 May 2015 13:25:34 -0700 (PDT)
Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t4KKPWUi027034 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 May 2015 13:25:32 -0700
Message-ID: <555CEDBC.80308@sonic.net>
Date: Wed, 20 May 2015 13:25:32 -0700
From: Erik Nordmark <nordmark@sonic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "rtg-dt-encap-considerations@ietf.org" <Rtg-dt-encap-considerations@ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVY3534nt6eceslRDTN+3Mu1nvfBu8ZVYPuieuqFEjkLqA7+6KCHLupnX5kzniZrqmeL5taKblys2N4FNMUptbB2
X-Sonic-ID: C;7DBOXS7/5BGeI/jYVPtzAg== M;zlJZXS7/5BGeI/jYVPtzAg==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dt-encap-considerations/wUONde55kA1-DW4t1O3ySr4Yhak>
Subject: [Rtg-dt-encap-considerations] Realized we should have a change log
X-BeenThere: rtg-dt-encap-considerations@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Design Team on Encapsulation Considerations discussion list <rtg-dt-encap-considerations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dt-encap-considerations/>
List-Post: <mailto:rtg-dt-encap-considerations@ietf.org>
List-Help: <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2015 20:25:35 -0000

So I added one from glancing at the diffs.
Let me know if I missed something.

    Erik

23.  Change Log

    The changes from draft-rtg-dt-encap-01 based on feedback at the
    Dallas IETF meeting:
    o  Setting the context that not all common issues might apply to all
       encapsulations, but that they should all be understood before
       being dismissed.
    o  Clarified that IPv6 flow label is useful for entropy in
       combination with a UDP source port.
    o  Editorially added a "summary" set of bullets to most sections.
    o  Editorial clarifications in the next protocol section to more
       clearly state the three areas.
    o  Folded the two next protocol sections into one.
    o  Mention the MPLS first nibble issue in the next protocol section.
    o  Mention that viewing the next protocol as an index to a table with
       processing instructions can provide additional flexibility in the
       protocol evolution.
    o  For the OAM "don't forward to end stations" added that defining a
       bit seems better than using a special next-protocol value.
    o  Added mention of DTLS in addition to IPsec for security.
    o  Added some mention of IPv6 hob-by-hop options of other headers
       than potentially can be copied from inner to outer header.
    o  Added text on architectural considerations when it might make
       sense to define an additional header/protocol as opposed to using
       the extensibility mechanism in the existing encapsulation
       protocol.
    o  Clarified the "unconstrained TLVs" in the hardware friendly
       section.
    o  Added references to draft-ietf-pwe3-congcons,
       draft-ietf-tsvwg-rfc5405bis, RFC2473, and RFC7325
    o  Removed reference to RFC3948.
    o  Updated the acknowledgements section.
    o  Added this change log section.