IETF Logo Mail Archive

[Softwires] ACTION REQUIRED: Proposed AUTH48 changes to draft-ietf-softwire-map-dhcp

Suresh Krishnan <suresh.krishnan@ericsson.com> Mon, 01 June 2015 04:29 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196571A1ADD; Sun, 31 May 2015 21:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 R8H0XMOKvbtN; Sun, 31 May 2015 21:29:36 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E1A1A1ADC; Sun, 31 May 2015 21:29:30 -0700 (PDT)
X-AuditID: c6180641-f79086d000001909-e2-556b7a383960
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AE.10.06409.83A7B655; Sun, 31 May 2015 23:16:40 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Mon, 1 Jun 2015 00:29:20 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Softwires WG <softwires@ietf.org>
Thread-Topic: ACTION REQUIRED: Proposed AUTH48 changes to draft-ietf-softwire-map-dhcp
Thread-Index: AdCcI4d1anQI68F0TaG6ylDTIBK6DA==
Date: Mon, 01 Jun 2015 04:29:20 +0000
Message-ID: <E87B771635882B4BA20096B589152EF628C744A4@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyuXSPn65FVXaoQV+rmcXDczEWh5dtZbLY 2h1rsXyGpgOLx5TfG1k9liz5yeTx+sB81gDmKC6blNSczLLUIn27BK6MGU/mshTcEKxYtX8T awPjRL4uRg4OCQETibv/Y7oYOYFMMYkL99azdTFycQgJHGWUOHN2MTuEs4xRYuP+J4wgVWxA DRt2fmYCsUUEVCWe7HzABmIzC6xklDg1NxnEFhYIlmj8+5YdoiZC4u3rP1C2nsSZ/zfZQRaz CKhILJnpARLmFfCVuDoJYjwj0BHfT61hghgpLnHryXwmiOMEJJbsOc8MYYtKvHz8jxXCVpL4 +Hs+O0S9jsSC3Z+gztGWWLbwNTPEfEGJkzOfsExgFJmFZOwsJC2zkLTMQtKygJFlFSNHaXFq WW66keEmRmAsHJNgc9zBuOCT5SFGAQ5GJR5eBZ/sUCHWxLLiytxDjNIcLErivBdVQ0KFBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MO5UKvL5lV1wZes0Tve4v583VM7sYL+wsL06XeD7VfdD Oo19vwPjvtirX5JvYTq+9tTrAG3Gk8ftgi/4zIn6dCB8j/uZm/f+RCsIi3/ge3OH59Ccv/++ XbTKalnk49DSdGLPVrHbilW/HBY+ui62e/lB89qlYv/r7ZZ95j+nNvOy0K2Yvq4bmZJKLMUZ iYZazEXFiQAu7v04ZgIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/softwires/zb0zq2XWXS9YopjOhUgmwIaWtaY>
Cc: "draft-ietf-softwire-map-dhcp.all@ietf.org" <draft-ietf-softwire-map-dhcp.all@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Subject: [Softwires] ACTION REQUIRED: Proposed AUTH48 changes to draft-ietf-softwire-map-dhcp
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 04:29:38 -0000

Hi all,
   There is a small clarification of DHCPv6 behavior that is in the 
process of being adopted by the dhcpv6bis work that will impact the MAP 
DHCP specification that is currently in the RFC Editor queue.

RFC 3315 states that servers don't send options that the clients did not 
request in the ORO. But it's not clear about what to do about 
encapsulated option (i.e. options that appear inside of other options). 
In the process of working on 3315bis, the dhc wg has concluded that any
option the client wants to see, whether encapsulated or not, needs to
appear in the ORO.

The following text change can update the draft to better reflect the new 
proposed behavior of the DHCPv6 servers, while still staying conformant 
to the current specifications.

OLD:
    This approach implies that all of the provisioning options MUST
    appear only within the container options.  The client MUST NOT
    request any of the provisioning options directly within an ORO.  MAP-
    DHCP clients that receive provisioning options that are not
    encapsulated in container options MUST silently ignore these options.
    DHCP server administrators are advised to ensure that DHCP servers
    are configured to send these options in the proper encapsulation.

NEW:
    This approach implies that all of the provisioning options
    appear only within the container options. MAP-
    DHCP clients that receive provisioning options that are not
    encapsulated in container options MUST silently ignore these options.
    DHCP server administrators are advised to ensure that DHCP servers
    are configured to send these options in the proper encapsulation.

ACTION REQUIRED:

Since this clarification is being proposed for AUTH48 I would like to do 
a consensus check to see if there are any objections in the wg to doing 
this change. Please respond to this email if you have any issues with 
the proposed text by end of day June 8 AOE. If there are no objections 
by then, we will go ahead with making this change.

Thanks
Suresh

v2.23.0 | Report a Bug | By Email