Re: [Int-dir] [6tisch] A review of https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 for INT-DIR

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 25 October 2016 09:14 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CDC1294AC; Tue, 25 Oct 2016 02:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.941
X-Spam-Level:
X-Spam-Status: No, score=-14.941 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 aFLVBSc9lJiR; Tue, 25 Oct 2016 02:13:56 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF94129462; Tue, 25 Oct 2016 02:13:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20555; q=dns/txt; s=iport; t=1477386835; x=1478596435; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6MCpBLfn6u8BAGQ3muNjMhJadci1wFtc9YbWjw+ir8g=; b=VtukTYuU8GSKNCHa0i9hSlALzBpQrcr31gCkrp4mM5Z2CCdQuTLJc7ta QToXkSUcKCVHX6Zyn7kngyFuaPXwYgY8LLZk81BaE/UbzqSE8CyrCGYJf UmOL8qRLnX2KfhQ1fMn+5Rw5xxcxDlpb3Vs8eggJd9h6QmvTuGyF67W+A Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B+AQDqIQ9Y/5tdJa1cGgEBAQECAQEBAQgBAQEBgnQ8AQEBAQEdWH0HjS6WfZQ/ggccAQqFMEoCgXQ/FAECAQEBAQEBAWIohGIBAQEEAQEBKjoEAwsQAgEIDgMDAQEBJAQHJwsUCQgBAQQOBQgBEog4DsFYAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY9hFWEZwwKhSkFmhYBhimJYoF1jhWHGYVvhAABHjZeg0gOgSxyAYZZgQABAQE
X-IronPort-AV: E=Sophos;i="5.31,545,1473120000"; d="scan'208,217";a="165703983"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2016 09:13:53 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u9P9DrE4005829 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Oct 2016 09:13:53 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Oct 2016 04:13:52 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 25 Oct 2016 04:13:52 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Charlie Perkins <charles.perkins@earthlink.net>
Thread-Topic: [Int-dir] [6tisch] A review of https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 for INT-DIR
Thread-Index: AdIuCgOtktmeAoQpRrysGX/nX1IU6wAlSOMAAAACKXA=
Date: Tue, 25 Oct 2016 09:13:36 +0000
Deferred-Delivery: Tue, 25 Oct 2016 09:13:09 +0000
Message-ID: <c6b27e031b9e41bd8e3d55031dd1e9bd@XCH-RCD-001.cisco.com>
References: <0c8d9a37da1648879577c72ce5b46ff1@XCH-RCD-001.cisco.com> <15417df8-abf5-4496-fb58-28d233445011@earthlink.net>
In-Reply-To: <15417df8-abf5-4496-fb58-28d233445011@earthlink.net>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.4]
Content-Type: multipart/alternative; boundary="_000_c6b27e031b9e41bd8e3d55031dd1e9bdXCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/3eUC9baPTB1LJadRSgWDG1yuHI8>
Cc: "draft-kivinen-802-15-ie@tools.ietf.org" <draft-kivinen-802-15-ie@tools.ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [Int-dir] [6tisch] A review of https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 for INT-DIR
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2016 09:14:00 -0000

Hello Charlie

Moving the vendor IE section to appendix would work for me just fine, but then I'd expect a sentence in the IANA section that explains that there is no reservation for vendors subtypes, rationale being in appendix or something. The move is more important if the doc stays standard track, but I do not see a good reason for that.

Note also that things can be required by an RFC without the RFC 2119 imperative (uppercase) form. That form is a clarification.

Take care,

Pascal

From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Charlie Perkins
Sent: mardi 25 octobre 2016 06:07
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: draft-kivinen-802-15-ie@tools.ietf.org; 6lo@ietf.org; 6tisch@ietf.org; int-dir@ietf.org
Subject: Re: [Int-dir] [6tisch] A review of https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 for INT-DIR


Hello Pascal,

I hope that the ADs can advise about the level of review required for additional assignments.  Your suggestion for RFC required is also reasonable, I think, given that the IETF is owning the assignment.  I observe that "RFC required" is about the same as "MUST be supported by an RFC", which means to me that the word "required" also carries with it the meaning specified by 2119.  But anyway I am happy to go along with whatever people decide about this.  I doubt that there is much room for misinterpretation one way or the other.

What do you think about my suggestion to put the "Vendor IE" section into the appendix?

Regards,
Charlie P.



On 10/24/2016 8:22 AM, Pascal Thubert (pthubert) wrote:
Dear all :

I am an assigned INT directorate reviewer for https://tools.ietf.org/html/draft-kivinen-802-15-ie-02. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

Document: draft-kivinen-802-15-ie
IEEE 802.15.4 Information Element for IETF
Reviewer: Pascal Thubert
Review Date: October 13, 2016
IETF Last Call Date: TBD

Summary:

Tero's draft was developed outside of the working group but is an enabler for solutions developed at 6lo and 6TiSCH. This review comes after the ones by Pat and then Charlie, who provided the adequate comments regarding IEEE802.15.4 and ANA. This review abstains to comment on that. Also, this review is made in the light of the Charlie's proposed update.

Major issues:

I am not sure that "expert review" is the right policy for section 8 on IANA considerations. This registry is for IETF use only. Suggestion is to use "RFC required":
"
   Future assignments in this registry are to be coordinated via IANA under the policy of "RFC Required" (see RFC 5226).
"

Intended Status for this document: Seems to me that  informational should be the right level; see for instance https://tools.ietf.org/html/draft-ietf-6lo-ethertype-request-01
Related: In the -04 that Charlie attached, I saw that uppercase imperatives were added. I do not think that's a good idea:

-         Imperative "MUST" in section 7 refers to the writing of other documents and is probably not appropriate.

-         Imperative "SHOULD" in section 7 does not refer to the behavior of the implementation of this document and is probably not appropriate either.

-         If those go away, ref to RFC 2119 is not needed and the specification can take the informational path, much easier


Minor issues:

 The need for section 5 does not appear until the IANA section. The way it is done works, but leaves the reader puzzled. Swapping 5 and 6 and then one last sentence saying that there is no need to block subtype IDs in the IETF IE for Vendor Specific work would have made the reading a bit smoother.

Do we need 20% of the subtypes for experimentations? 240 to 255 seems enough to me...


Many thanks, Tero, for this much needed work!

Pascal






_______________________________________________

6tisch mailing list

6tisch@ietf.org<mailto:6tisch@ietf.org>

https://www.ietf.org/mailman/listinfo/6tisch