Re: [T2TRG] IPv6 RA Option being specified as JSON-only
Dave Thaler <dthaler@microsoft.com> Wed, 24 July 2019 15:12 UTC
Return-Path: <dthaler@microsoft.com>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9117E12038A for <t2trg@ietfa.amsl.com>; Wed, 24 Jul 2019 08:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 qh_xFlRV4w71 for <t2trg@ietfa.amsl.com>; Wed, 24 Jul 2019 08:12:01 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760125.outbound.protection.outlook.com [40.107.76.125]) (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 11BEA1203B0 for <T2TRG@irtf.org>; Wed, 24 Jul 2019 08:11:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PqLA4iCrGaX2LaVvAaLEBdJlKe6LDvEgVqYlwakv4D1L4x/SYC6vR40lwtgwG6eBMKwPMAMq0WhmSwNzFHUjOR2JoJbqqlndF5u/j7CJ2uPSCwuNaSwg4XbyNww3adCggkoRACBmLMkAf85y00qUgm63Y1wyeQW0CqU/ekcTYnN5eGSP4LbgFc/C3zJpZF4ivhy6u7s1o/ptq/sbWRl6FthRPSZI282rarI0RwikYBnwsWcJtA8j5YOhpSjppUzD+/23/yHrPoZNyVTLkKMkvI2CQRNK00pXBdsvxV8LfyXKuxblhxtsp9si3sOFbZDzpDkks9NEXNbfa/MHCbTTsw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+3iTHR+4qp159nPeMVEIJCNE6oNbhrkfvsTbwpqGEMU=; b=bUUlsRJF16UepQMsVUiv1jPF7tYu98mwf5Zd1kP4D+7mVzGL4sZTIhatm3VfI44P/U/A+9/Gs1hJ0wLYrw8CYjGHx76InMENnrEu/Ylcz7xiPO9Bmq1ZempzNSkixSoJgOfUAUBRke5W6Kjxw7EYqvMnrns5sR/U5Ad/OUiIngLiEZ+T2IZHXXaqaYg2xhay8FJR0kDFV3nOyAqp1PctyGrY+DAk/P+PYd5/G7G/ZypJoAhj45zvx/w3ffKkEEIxH2IY+XMZo0LHpQyXY9oHojailrVHa9cyUMDKZqAnTt1of0kYDeu+xJmMOcgwDokVv5oxIGPEwHOmIlE6qEJG1w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+3iTHR+4qp159nPeMVEIJCNE6oNbhrkfvsTbwpqGEMU=; b=Aq24sy4o/kv0bVTzsHyYXUvzpIiXgVPNx0FF0JOaumLVmKpTBRrEtCZ1O384SFa1ThE90whK7TaldihT0aeH2/Sxo9Jd+wEzG9Sxbx0zeVQIosfW8vR7W9iOsYZdiqKqGyTwhJtm7VMYSIt+savRgG0AzgLUNex5c9K7FcmniGI=
Received: from MWHPR21MB0784.namprd21.prod.outlook.com (10.173.51.150) by MWHPR21MB0799.namprd21.prod.outlook.com (10.175.142.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.5; Wed, 24 Jul 2019 15:11:52 +0000
Received: from MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::7de1:e6c1:296:4e82]) by MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::7de1:e6c1:296:4e82%5]) with mapi id 15.20.2136.000; Wed, 24 Jul 2019 15:11:52 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "T2TRG@irtf.org" <T2TRG@irtf.org>
Thread-Topic: IPv6 RA Option being specified as JSON-only
Thread-Index: AdVCHjT9QtWFmE7RQz6N5SstA2sxlAAE4EzQ
Date: Wed, 24 Jul 2019 15:11:52 +0000
Message-ID: <MWHPR21MB0784B3B771E71710BB9C4E21A3C60@MWHPR21MB0784.namprd21.prod.outlook.com>
References: <MWHPR21MB07841DFAFE463A9B5E3F4D8AA3C60@MWHPR21MB0784.namprd21.prod.outlook.com>
In-Reply-To: <MWHPR21MB07841DFAFE463A9B5E3F4D8AA3C60@MWHPR21MB0784.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-24T12:49:50.5443432Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=1f66ed39-9620-4834-a74e-7b3060ece5c6; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com;
x-originating-ip: [2001:67c:370:128:20b1:f5f6:1f25:e810]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ee4a0159-211f-4003-8445-08d710494227
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:MWHPR21MB0799;
x-ms-traffictypediagnostic: MWHPR21MB0799:
x-microsoft-antispam-prvs: <MWHPR21MB07990DCBE8C3E634EF61D300A3C60@MWHPR21MB0799.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(136003)(376002)(346002)(396003)(366004)(189003)(199004)(33656002)(76116006)(99936001)(2351001)(10290500003)(8990500004)(7696005)(66476007)(66616009)(66556008)(7736002)(74316002)(6116002)(229853002)(76176011)(790700001)(6916009)(478600001)(22452003)(5024004)(256004)(6436002)(99286004)(71190400001)(71200400001)(316002)(14454004)(54896002)(81166006)(81156014)(8676002)(8936002)(486006)(446003)(86362001)(476003)(52536014)(68736007)(5660300002)(11346002)(66574012)(2906002)(6246003)(2501003)(55016002)(2940100002)(64756008)(66446008)(66946007)(9686003)(53936002)(236005)(102836004)(10090500001)(25786009)(186003)(6506007)(53546011)(46003)(6306002)(5640700003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0799; H:MWHPR21MB0784.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: tGfuNQyNp0Beg4V5IBQu/3TGeOLD8hqkoXwjbmlfqATTWmUC4Bj/d+KcNkaDS/kUcLc0CQBGqb43+JT0fHWQcwnmbdAoKm9Vj1POAw3kt1lpZdLYRS2bTOEJbWcBz9hF0e6Ax+11LEixxIBDbxMBLXL7QvHQNj45hD/snBFfzqx5qrPyHudrcYh6TyKR9lV0AkLWAoxcC3bLOwe6Nlf0IrrUc1Ng4RLpDtueRHyGHkntg06glQBXVdvd59fc1JCKm97FI4tmYhdYV46aSovdOZ8beOef1avBiOBQD+3CI1TRzcmDd0rH9jAXec9F6vcAYIhLTd3MnughYsMx8nkxoHgBcWNZS0Gkm+hqFXNHxbkVRh5bYv+e0UFVhcGhLHo+lfx7cTpUzJKG/OfCuGnUuYnbmvCRCempMiewgs0oG3I=
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_004_MWHPR21MB0784B3B771E71710BB9C4E21A3C60MWHPR21MB0784namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ee4a0159-211f-4003-8445-08d710494227
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 15:11:52.1059 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dthaler@ntdev.microsoft.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0799
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/DAWH0SgG1a_U__N6yyyP1QYuzi0>
Subject: Re: [T2TRG] IPv6 RA Option being specified as JSON-only
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 15:12:15 -0000
Attached is Tommy’s message to the int-area list, which contains a proposed paragraph about CBOR. Relevant snippet is: > Explained the intended use of the JSON in the scope of this document, And why we're not doing CBOR here: > > The additional information related to a PvD is specifically intended > to be optional, and is targeted at optimizing or informing the > behavior of user-facing hosts. This information can be extended to > provide hints for host system behavior (such as captive portal or > walled-garden PvD detection) or application behavior (describing > application-specific services offered on a given PvD). This content > may not be appropriate for light-weight Internet of Things (IoT) > devices. IoT devices might need only a subset of the information, > and would in some cases prefer a smaller representation like CBOR > ([RFC7049]). Delivering a reduced version of the PvD Additional > Information designed for such devices is not defined in this > document. If you have comments, please respond to the int-area message. Dave From: T2TRG <t2trg-bounces@irtf.org> On Behalf Of Dave Thaler Sent: Wednesday, July 24, 2019 8:50 AM To: T2TRG@irtf.org Subject: [T2TRG] IPv6 RA Option being specified as JSON-only draft-ietf-intarea-provisioning-domains is the draft I mentioned that’s in WGLC and uses JSON only (see section 4). I raised the issue of CBOR support for constrained nodes during the meeting yesterday. Anyone who believes that constrained nodes would care about this draft and would need CBOR, please say so on the intarea@ietf.org<mailto:intarea@ietf.org> list. Dave
--- Begin Message ---Hello INTAREA, Thanks to everyone for their feedback yesterday on the various proposals for the -06 version of draft-ietf-intarea-provisioning-domains. I've made several updates to the Pull Request (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FIPv6-mPvD%2Fmpvd-ietf-drafts%2Fpull%2F11&data=02%7C01%7Cdthaler%40microsoft.com%7C530d87d93e0f4e050fee08d7103f7643%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636995737062385906&sdata=iom6R1JrLljSLzyAGQv5D8%2BvZXH4m%2Fb5KZ8iUGJ1wCY%3D&reserved=0) based on the feedback we received. Please take a look at the changes, detailed here, and let us know if this works for you! Best, Tommy Here is a summary of the changes made since yesterday: Clarify DNS Resolution (Paul Hoffman's comments) ======================================= Added the following paragraph: PvD-aware applications will be able to select which PvD(s) to use for DNS resolution and connections, which allows them to effectively use multiple Explicit PvDs. In order to support non-PvD-aware applications, however, PvD-aware hosts SHOULD ensure that non-PvD- aware name resolution APIs like "getaddrinfo" only use resolvers from a single PvD for each query. More discussion is provided in Section 5.2.1 of [RFC7556]. Normative language around backoff timers (Gorry's comments) ================================================ Changed text to say: o When a host performs a JSON object update after it detected a change in the PvD Option Sequence Number, it MUST add a delay before sending the query. The target time for the delay is calculated as a random time between zero and 2**(Delay * 2) milliseconds, where 'Delay' corresponds to the 4-bit unsigned integer in the last received PvD Option. o When a host last retrieved a JSON object at time A that includes a expiry time B using the "expires" key, and the host is configured to keep the PvD information up to date, it MUST add some randomness into its calculation of the time to fetch the update. The target time for fetching the updated object is calculated as a uniformly random time in the interval [(B-A)/2,B]. JSON, I-JSON, CBOR (Dave Thaler, Erik Kline, Erik Nygren's comments) ======================================================== Specified that we expect the reduced profile of JSON (I-JSON): This JSON object is restricted to the restricted profile of I-JSON, as defined in [RFC7493]. Explained the intended use of the JSON in the scope of this document, And why we're not doing CBOR here: The additional information related to a PvD is specifically intended to be optional, and is targeted at optimizing or informing the behavior of user-facing hosts. This information can be extended to provide hints for host system behavior (such as captive portal or walled-garden PvD detection) or application behavior (describing application-specific services offered on a given PvD). This content may not be appropriate for light-weight Internet of Things (IoT) devices. IoT devices might need only a subset of the information, and would in some cases prefer a smaller representation like CBOR ([RFC7049]). Delivering a reduced version of the PvD Additional Information designed for such devices is not defined in this document. DHCPv6 Association (Discussion from Suresh, Lorenzo, Ted, Erik Kline) ======================================================= After the meeting, we had a hallway conversation, and brought up the possibility of limiting the scope of associating DHCPv6 information to the set of RA information that is currently presented to legacy (non-PvD-aware) hosts. This provides the greatest amount of backwards-compatibility, without introducing unnecessary logic for comparing prefixes and addresses between the two sources, etc. This change involves adding a clarifying definition for a concept that was already present, but not defined: Legacy-Visible Explicit PvD: An Explicit PvD that contains information that non-PvD-aware hosts detect and use. These PvDs are usable by both legacy and PvD-aware hosts, although PvD-aware hosts can be aware of the identifier and additional information associated with the PvD. Any RA that contains a PvD Option defines an Explicit PvD, which will be visible and usable by PvD-aware hosts. If an RA contains only a PvD Option at its top-level, with all other RA options contained within the PvD Option (with the R-flag set), the Explicit PvD will be visible only to PvD-aware hosts. If, on the other hand, an RA contains other options at the top-level, and the PvD Option does not have the R-flag set, the Explicit PvD will be visible to both PvD- aware and legacy hosts. Such PvDs are referred to as Legacy-Visible Explicit PvDs. The text for DHCPv6 association can then be reduced to the following: 3.4.1. DHCPv6 configuration association When a PvD-aware host receives DHCPv6 [RFC8415] configuration elements, it SHOULD associate the received information with all Implicit PvDs and Legacy-Visible Explicit PvDs. This is intended to maintain behavior of how data is associated for non-PvD-aware hosts. _______________________________________________ Int-area mailing list Int-area@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=02%7C01%7Cdthaler%40microsoft.com%7C530d87d93e0f4e050fee08d7103f7643%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636995737062385906&sdata=RM06FWx%2BjW%2FjllCeeuFoZNL3F3wDjmUUsk15yLVu7vo%3D&reserved=0--- End Message ---
- [T2TRG] IPv6 RA Option being specified as JSON-on… Dave Thaler
- Re: [T2TRG] IPv6 RA Option being specified as JSO… Dave Thaler