IETF Logo Mail Archive

[6lo] draft-ietf-6lo-mesh-link-establishment-00 (was: Review of draft-kelsey-6lo-mesh-link-establishment)

Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> Wed, 30 March 2016 18:54 UTC

Return-Path: <Gabriel.Montenegro@microsoft.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C990D12D8BD for <6lo@ietfa.amsl.com>; Wed, 30 Mar 2016 11:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 7FjUbT0AKy54 for <6lo@ietfa.amsl.com>; Wed, 30 Mar 2016 11:54:00 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E8412D8B2 for <6lo@ietf.org>; Wed, 30 Mar 2016 11:54:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bZRRSAU6CjIbetfjIEEJoHxnjXPm4QtsjzqUDoeWTZo=; b=oet9up1j9GJFev3LlxvgzLBYEMMU0biIG95yROFvLUsLzfcqGyk3l6Ia6Gb8XQr57Wiy71FbcEZ8Bj8fupkMDAHhqG3oQIRhKxHDfncdV+4kTs/FpB1vjXJnW5rKJG3+PgvnoNZkr50d2a7DxIJO1O7mermNE4SFfswXa8oZLLM=
Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 30 Mar 2016 18:53:42 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.139]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.139]) with mapi id 15.01.0434.023; Wed, 30 Mar 2016 18:53:42 +0000
From: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Richard Kelsey <Richard.Kelsey@silabs.com>
Thread-Topic: draft-ietf-6lo-mesh-link-establishment-00 (was: Review of draft-kelsey-6lo-mesh-link-establishment)
Thread-Index: AdGKspI4+yztdbIIQCGfUTKzeReC0A==
Date: Wed, 30 Mar 2016 18:53:42 +0000
Message-ID: <BN1PR03MB072D29138530D02F0CD428495980@BN1PR03MB072.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:3::2b8]
x-ms-office365-filtering-correlation-id: c8bfb50b-df09-4a2c-acff-08d358cc9d83
x-microsoft-exchange-diagnostics: 1; BN1PR03MB072; 5:fe125O2PszMMq42vwacG81BrlwIKKEUBdrnr2qithtnBakxuevrNV6yqZCoE23a/uDHYBNAF15abFWsBptOMLzOa7LUpKFVComdQ4I5JOTwYkWCIog0eXQPkcGYjkmo0ys4CWH7nf1Q7172Z976vuA==; 24:fkxBxT9SoHXNT1s8JJiE6I7rEujJln1VUWh2RuPxzCJJ6qMfJwZzrguNhoQH0QBVVmKXH4XUTK42X5jjtqHhGYuhsEb1vtoQwthXn1eLCZc=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB072;
x-microsoft-antispam-prvs: <BN1PR03MB0728AB78D161EB87AE2D4B795980@BN1PR03MB072.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BN1PR03MB072; BCL:0; PCL:0; RULEID:; SRVR:BN1PR03MB072;
x-forefront-prvs: 08978A8F5C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(99286002)(1220700001)(1096002)(5005710100001)(2900100001)(6116002)(10400500002)(10290500002)(2501003)(86362001)(102836003)(5004730100002)(122556002)(586003)(76576001)(33656002)(92566002)(19580395003)(5001770100001)(15975445007)(81166005)(87936001)(74316001)(230783001)(3660700001)(2906002)(4326007)(189998001)(11100500001)(5008740100001)(54356999)(3280700002)(5003600100002)(50986999)(5002640100001)(8990500004)(229853001)(10090500001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB072; H:BN1PR03MB072.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2016 18:53:42.6568 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB072
Archived-At: <http://mailarchive.ietf.org/arch/msg/6lo/I5NpCqA1lzQhTuWZOtdYrbm3SLk>
Cc: robert cragie <robert.cragie@gridmerge.com>, "6lo@ietf.org" <6lo@ietf.org>
Subject: [6lo] draft-ietf-6lo-mesh-link-establishment-00 (was: Review of draft-kelsey-6lo-mesh-link-establishment)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2016 18:54:03 -0000

<WG chair hat off>

After Peter's review the abstract's summary of MLE's capabilities was modified. However, section 4 repeats the old language. Suggest aligning with the revised language in the abstract.

Furthermore, I'd add the clarifications along the lines of what you suggest for the 3 capabilities, namely:

 - on capability #1: This is the primary purpose for MLE.
 - on capability #2: This could be done in lots of ways.  ZigBee IP happened to use MLE.  Removing this functionality would not affect the rest of the protocol.
 - on capability #3: is an optimization to make 1) more efficient.  It isn't strictly necessary.  

I'm a bit concerned about the lack of clarity in terms of applicability. For example, you say:
" The draft describes MLE as used in ZigBee IP, not as it is used in Thread.  "
" the version of MLE described in the draft"

So it seems like this version of the protocol currently applies only to ZigBee IP and ZigBee NAN and no other standards. If so, I'd suggest making that explicit. There's also the question of other versions of MLE. Is there an issue to tell them apart easily? How would one do that?

IANA assignments are per IETF Review. For a protocol whose users are a separate organization, this might be too onerous. I would imagine that Specification Required might be easier for other organizations to further develop the protocol while avoiding collisions and further interop issues (https://tools.ietf.org/html/rfc5226#section-4.1). 

Thanks,

Gabriel

v2.23.0 | Report a Bug | By Email