[dhcwg] IETF-94 Follow-up - draft-ietf-dhc-rfc3315bis - ORO (Ticket #81)

"Bernie Volz (volz)" <volz@cisco.com> Tue, 10 November 2015 02:15 UTC

Return-Path: <volz@cisco.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 63CCA1AD2B2 for <dhcwg@ietfa.amsl.com>; Mon, 9 Nov 2015 18:15:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 TKCeAzQzm6ll for <dhcwg@ietfa.amsl.com>; Mon, 9 Nov 2015 18:15:01 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0277B1AD0A1 for <dhcwg@ietf.org>; Mon, 9 Nov 2015 18:15:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14569; q=dns/txt; s=iport; t=1447121700; x=1448331300; h=from:to:subject:date:message-id:mime-version; bh=nNVpsA7d8E1uu+10u3Y8ikEliH6Y2FeEsqACPOaqeIk=; b=UYChhAIvJ9gFBDd2oDcj+Qc8vqdMRHhMKiHCJDv1ewdsdSfREoqwNDkK Uixb9pUz4nlkbwBF9ewNXPRfrlMPsVC8pOtP8LiAiB8qmcmE2cK2khd2C ud+TxzW3cY/j+f4bX5ZAjXY+2QFQHKQSUot+CUFrUDQopDZKTGFFYulfZ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B7AwAIUkFW/4oNJK1egm5NU28GvB+BbysBDYFjIYVvgUE4FAEBAQEBAQF/C4Q6Ai1BHQGBACYBBBuIJg2hLaBJAQEBAQEBBAEBAQEBAQEcjRIBgwEGQIQxBZJng2EBhR2IAoFiSYN3jVaIUwERDgEBQoQEcgGEJoEHAQEB
X-IronPort-AV: E=Sophos; i="5.20,268,1444694400"; d="scan'208,217"; a="43512190"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 10 Nov 2015 02:14:59 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tAA2ExaS004390 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <dhcwg@ietf.org>; Tue, 10 Nov 2015 02:14:59 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 Nov 2015 20:14:59 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Mon, 9 Nov 2015 20:14:59 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: IETF-94 Follow-up - draft-ietf-dhc-rfc3315bis - ORO (Ticket #81)
Thread-Index: AdEbWtRiFITqS80oSsuW0Gs5QAt/qA==
Date: Tue, 10 Nov 2015 02:14:59 +0000
Message-ID: <00b8352a4557420d90245e81d69389c9@XCH-ALN-003.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.1.197]
Content-Type: multipart/alternative; boundary="_000_00b8352a4557420d90245e81d69389c9XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/Y18tHpHGHSO9cXEc1WTSwEaXJUA>
Subject: [dhcwg] IETF-94 Follow-up - draft-ietf-dhc-rfc3315bis - ORO (Ticket #81)
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: Tue, 10 Nov 2015 02:15:03 -0000

Hi:

This is to confirm on the DHC WG mailing list our proposal to resolve the RFC3315bis ticket #81 (ORO) by updating RFC3315bis to handle the options specified in a client's ORO as follows (see http://trac.tools.ietf.org/group/dhcpv6bis/ticket/81 and https://www.ietf.org/proceedings/94/slides/slides-94-dhc-5.pdf for more details):

*       Protocol-required options MUST NOT appear in ORO
-      3315bis will enumerate options which MUST NOT appear in the ORO (i.e., Client ID, Server ID, ...)
-      Will request IANA to add a column in option registry
*       Other top-level options MUST appear in ORO or will not be sent by server
-      Slight change from RFC 3315, which allows the server to send extra options
-      Exception: options MAY be administratively configured to be sent on server
*       Only container options MUST appear in the ORO:
-      The server MUST send all options that are eligible to be encapsulated in that container, if that container option is requested
*       Those options that are only encapsulated in a container MUST NOT be in the ORO
*       Exception: The ORO can be used to signal support for a feature even when that option is encapsulated, as in the case of the Prefix Exclude option (RFC 6603)
-      However, this requires special processing by the server

If you want to comment on this (or ask for clarification), please respond by 11/23. The RFC3315bis team will otherwise update the draft as per the above.

Thanks.


-          Bernie