From nobody Wed Oct 21 21:01:34 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0D11B3700; Wed, 21 Oct 2015 21:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1aoPwHUShvLH; Wed, 21 Oct 2015 21:01:31 -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 41C221B2D97; Wed, 21 Oct 2015 21:01:28 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-a8-5627f2d7369e Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 76.88.26730.7D2F7265; Wed, 21 Oct 2015 22:17:27 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Thu, 22 Oct 2015 00:01:26 -0400 From: Suresh Krishnan To: "int-dir@ietf.org" , "draft-ietf-6tisch-minimal.all@ietf.org" Thread-Topic: INT DIR review of draft-ietf-6tisch-minimal-12.txt Thread-Index: AdEMflKoUczlhpT5TGOloxikuM9L1A== Date: Thu, 22 Oct 2015 04:01:26 +0000 Message-ID: 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+NgFrrILMWRmVeSWpSXmKPExsUyuXSPn+71T+phBv++q1scnjGX2eLRlW4W ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlvH8QXPCOt2JmwyfWBsa53F2MnBwSAiYS/RffsEDY YhIX7q1n62Lk4hASOMoosf/zJmYIZzmjxI2OQ2wgVWxAHRt2fmYCsUUEGhglJraEgdjCAtYS f3ZNZISIO0hce3qbBcLWkzgz5xUriM0ioCpx8cgLoKEcHLwCvhKXd7uBhBmBFn8/tQZsJLOA uMStJ/OZIA4SkFiy5zwzhC0q8fLxP1YIW0ni4+/57BD1OhILdn9ig7C1JZYtfA1WzysgKHFy 5hOWCYzCs5CMnYWkZRaSlllIWhYwsqxi5CgtTi3LTTcy3MQIDOhjEmyOOxgXfLI8xCjAwajE w5swSz1MiDWxrLgy9xCjBAezkgjvP0uNMCHelMTKqtSi/Pii0pzU4kOM0hwsSuK882bcDxUS SE8sSc1OTS1ILYLJMnFwSjUwTn99/Mz8ayuTiic/vy/RYqcfkSxbefJJT3So+BS12Znf6l8p bww33tA20XnJuZ+NlZ/0WD5sv7F0+nnpk4cVVpaaqyfrszCz6BR692330VnI+kvibOb0ZoWQ 0r91f06oCIj8fXuoSyX73zkLM7UNP5nvlp5sj9oTpWvrXVJ2VJ7NwidEfGGDEktxRqKhFnNR cSIASv8JKmQCAAA= Archived-At: Subject: [Int-dir] INT DIR review of draft-ietf-6tisch-minimal-12.txt X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 04:01:33 -0000 I am an assigned INT directorate reviewer for =0A= . These comments were written primarily f= or =0A= the benefit of the Internet Area Directors. Document editors and shepherd(s= ) =0A= should treat these comments just like they would treat comments from any = =0A= other IETF contributors and resolve them along with any other Last Call =0A= comments that have been received. For more details on the INT Directorate, = =0A= see http://www.ietf.org/iesg/directorate.html.=0A= =0A= Summary: The draft is almost ready for publication but I have two comments = =0A= that you may want to address.=0A= =0A= Major=0A= =3D=3D=3D=3D=3D=0A= =0A= * Intended Status:=0A= =0A= This looks more like a recommended set of network configuration parameters = =0A= than a new protocol definition. Has the wg considered whether the Proposed = =0A= Standard status is appropriate (as opposed to Info or BCP)?=0A= =0A= * Section 10.1.1=0A= =0A= I have a question about the Sp computation. Looks like the Sp value needs t= o =0A= be between 1 and 9. In my view, the recommended method (3*ETX)-2 yields =0A= values between 1 and 10. This needs to be fixed.=0A= =0A= This is how I see it.=0A= =0A= On a very high quality link, if there are no retransmissions required ETX = =0A= will be 1/1 =3D> 1. Sp will be (3*1)-2 =3D> 1=0A= =0A= On a very poor quality link where the packet only gets through after the fu= ll =0A= 3 retries ETX will be 4/1 =3D> 4. Sp will be (3*4)-2 =3D> 10.=0A= =0A= Is my calculation correct?=0A= =0A= Editorial=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= =0A= Section 3.2=0A= =0A= s/maintin/maintain/=0A= =0A= Section 3.3=0A= =0A= s/if none is/if none are/=0A= =0A= Thanks=0A= Suresh=0A= From nobody Thu Oct 22 12:01:30 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF13A1B3BEB; Thu, 22 Oct 2015 12:01:28 -0700 (PDT) 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 ZE7BFOrOhLNy; Thu, 22 Oct 2015 12:01:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E3C1B3BE2; Thu, 22 Oct 2015 12:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8758; q=dns/txt; s=iport; t=1445540477; x=1446750077; h=from:to:cc:subject:date:message-id:mime-version; bh=iThEoLjx4QCTr34bi65KPfeoZgm4PEY2Cu4lZAFuJS4=; b=CUdPxwS/N/B2Ps4pB0J0ZxNnVuhNdUuDNScZQbxtbi9u++eDknN3QZJv gVCdTVijQvOaLFQeGUj6WdPwggtBOGxH3IlGDTFMy6194ItPcYiewval5 2KVRk2zbX2se4M0yZDF4fakubDi8x17xaiNSkIw7Hb5ekml5x/wLMJDst I=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvAgCaMSlW/5hdJa1egzZUbwa+HA6BWSOFeoFNOBQBAQEBAQEBgQqEMQQjVhIBSgI0JwQBDQ4FDYgVDbJDknwBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYZ3ghCHe4JwMYEUBZJdg04Bgk2BYYhvgViHY5JqAR8BQ4QDcgGFPIEGAQEB X-IronPort-AV: E=Sophos;i="5.20,183,1444694400"; d="asc'?scan'208,217";a="43574834" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2015 19:01:16 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9MJ1Gb3002190 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 19:01:16 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 14:00:55 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 14:00:55 -0500 From: "Carlos Pignataro (cpignata)" To: "int-dir@ietf.org" , "int-ads@ietf.org" Thread-Topic: Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 Thread-Index: AQHRDPv6FKCF96/7CU+NxDHsiz8fgg== Date: Thu, 22 Oct 2015 19:00:55 +0000 Message-ID: <32E92224-BB99-4B2C-8138-8DDB4A6DC054@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.54.194] Content-Type: multipart/signed; boundary="Apple-Mail=_E9E8F398-469D-413B-B1D9-A33A1C7DD47E"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-softwire-mesh-mib.all@ietf.org" Subject: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 19:01:28 -0000 --Apple-Mail=_E9E8F398-469D-413B-B1D9-A33A1C7DD47E Content-Type: multipart/alternative; boundary="Apple-Mail=_1A630693-7FBA-41CE-9B91-2086B3265BA5" --Apple-Mail=_1A630693-7FBA-41CE-9B91-2086B3265BA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I am an assigned INT directorate reviewer for = draft-ietf-softwire-mesh-mib-11. 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/intarea.html = . This document defines MIB objects to manage softwire mesh solutions, and = targets the Standards Track. I have a number of comments and concerns with this document, which = amount to requesting the ADs to take a closer look: 3. Terminology This document uses terminology from the softwire problem statement RFC 4925 [RFC4925] and the softwire mesh framework RFC 5565 [RFC5565]. CMP: I think terminology from RFC 5512 is also heavily used. 5.1. The swmSupportedTunnelTable Subtree According to section 4 of RFC 5512 [RFC5512], current softwire mesh tunnel types include IP-IP, GRE and L2TPv3. CMP: This is true, but at the same time there are now many other = =E2=80=9Ccurrent tunnel types=E2=80=9D (which are actually BGP Tunnel = Encapsulation Attribute Tunnel Types). See = http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel= -types = Specifically the ones introduced by RFC5566 ought to be = included. CMP: This comment also applies to swmSupportedTunnelType XX. Missing sub-TLVs CMP: If the Tunnel Type is one which requires encapsulation information = (e.g., L2TPv3 Session ID, Cookie, GRE Key, etc.), how is that = information managed? I cannot seem to find it in the MIB Module. See = Section 4.1 of RFC 5512. CMP: Similarly, what about Protocol Type and Color (S4.2 and 4.3 of RFC = 5512), and IPsec Tunnel Authenticator (RFC 5566)? CMP: Similarly, what about the Load-Balancing Block values from RFC = 5640? Without this, an ECMP-aware L2TPv3 tunnel will be misunderstood. 8. Security Considerations The swmMIB module can be used for configuration of certain objects, CMP: How is this so, without read-write or read-create? 11. References 11.1. Normative References CMP: Curiously, I do not see RFC 5566 or RFC 5640 referenced. Hope these help! Thanks, =E2=80=94 Carlos. --Apple-Mail=_1A630693-7FBA-41CE-9B91-2086B3265BA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

I am an assigned INT directorate = reviewer for draft-ietf-softwire-mesh-mib-11. 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/intarea.html.

This = document defines MIB objects to manage softwire mesh solutions, and = targets the Standards Track.

I have a number of comments and = concerns with this document, which amount to requesting the ADs to take = a closer look:

3.  Terminology

   This document uses terminology from the softwire = problem statement
   RFC = 4925 [RFC4925] and the softwire mesh framework RFC = 5565
   [RFC5565].

CMP: I think terminology = from RFC 5512 is also heavily used.

5.1.  The swmSupportedTunnelTable = Subtree

   According
   to = section 4 of RFC 5512 [RFC5512], current softwire mesh = tunnel
   types include IP-IP, GRE and = L2TPv3.

CMP: This is true, but at the same time there are now many = other =E2=80=9Ccurrent tunnel types=E2=80=9D (which are actually BGP = Tunnel Encapsulation Attribute Tunnel Types). See http://www.iana.org/assignments/bgp-parameters/bgp-parameters.x= html#tunnel-types Specifically the ones introduced by RFC5566 = ought to be included.

CMP: This comment also applies to = swmSupportedTunnelType

XX. Missing sub-TLVs

CMP: If the Tunnel Type is one which = requires encapsulation information (e.g., L2TPv3 Session ID, Cookie, GRE = Key, etc.), how is that information managed? I cannot seem to find it in = the MIB Module. See Section 4.1 of RFC 5512.

CMP: Similarly, what about Protocol = Type and Color (S4.2 and 4.3 of RFC 5512), and IPsec Tunnel = Authenticator (RFC 5566)?

CMP: Similarly, what about the Load-Balancing Block values = from RFC 5640? Without this, an ECMP-aware L2TPv3 tunnel will be = misunderstood.

8.  Security Considerations

   The swmMIB module can be used = for configuration of certain objects,

CMP: How is this so, without read-write = or read-create?

11.  References

11.1. =  Normative References

CMP: Curiously, I do not see RFC 5566 or RFC 5640 = referenced.

Hope= these help!

Thanks,

=E2=80=94 Carlos.

= --Apple-Mail=_1A630693-7FBA-41CE-9B91-2086B3265BA5-- --Apple-Mail=_E9E8F398-469D-413B-B1D9-A33A1C7DD47E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWKTJ6AAoJEIXgpQGOZny9OgQQAK/w3oliBONUn8/wpHyBnLoZ fPvdWZYzQRnvRTda90B4FLnmZUE61IQh0y2kMhyHjjmDF8OhFZacArNLbOb0RWPi 7Fw3wPUoexjfwSYwlSicWpqpecIoFYNUjPQ/Yq6QVh38/rxZgl6r15UGIwifABt9 UQPep6vxSJVzku7MUYdfJshGZmVm1NF0T0ZeN9zL7q4ziJqGAHU8injqO7grZtWV qqugiKEMkzxTZV3umSRsd911sCgsvRZ6YhIhnrT1WK7CCKXvaX1hBO4zx9i6AVT2 5nMINB9AGPxwkSO0Xk5NZ22r0IOevJG4+OvSOxpFXxBzL0mdxn2QCT/PzXqe81gX RrQYtTqxca2VNqVjgMZaNg1EHNmWVCBSPIwvmV0+Qd02/FmNHCsKLeejGCGbJdh7 eGB9OeTj9Wz4Tm962pF6T/6Hf5kZFGi+pMjJBRuRuLolQLe9bfrdNAmaeENDWW2j i6toof1Ix5SeLrCZrsAFW/LspXRiqe5Tsl6u/FyklmS5IkXYBik1Ny2qCbjqGJvA ovpPxhbms6deaI4wgZ/ivn3JO3OuUja80GSq713BxOIFS8zGAgxjye9xbGHEDRvb 0NEX07qUUrQG7GyNn4QcuuLyrDYgYgyUpbZYIuCLHzgUwDWVAcGuqX1fF+64wYS8 SvovH3xoYWDglfjzl9gR =OaTw -----END PGP SIGNATURE----- --Apple-Mail=_E9E8F398-469D-413B-B1D9-A33A1C7DD47E-- From nobody Thu Oct 22 12:01:41 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38201A8A0C; Thu, 22 Oct 2015 12:01:40 -0700 (PDT) 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 ONGHqqDOzURO; Thu, 22 Oct 2015 12:01:32 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A37C1B3BE8; Thu, 22 Oct 2015 12:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9009; q=dns/txt; s=iport; t=1445540480; x=1446750080; h=from:to:cc:subject:date:message-id:mime-version; bh=Ubhmw2MoKt6rIlkSKmygszFM9grj8W6DsJHA8/ayYdI=; b=ABU8jf7mtb3UCrFz68l+tUyScjTi2R306ob2ICvbB2aBC4bC0fm7BQFl 25lkSnKqJ5qFjr98RW9Ix3R70dU+Crl2hA/zsNHeGmQR8uuYlZoQ+kzrS NVFXU99SxsGXoSup25/Vl5/IO0Q/QeCzLWtgZ0XRracbWUGwgbGcXQPn0 8=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvAgDCMSlW/5xdJa1egzZUbwa+HA6BWSGFfIFNOBQBAQEBAQEBgQqEMQQjVhIBBkQCNCcEAQ0OBQ2IFQ2VDJ03knwBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYZ3ghCHdwSCcDGBFAWSXYNOAYJNgWGIb4FYhD+DJJJqAR8BQ4QDcgGFPIEGAQEB X-IronPort-AV: E=Sophos;i="5.20,183,1444694400"; d="asc'?scan'208,217";a="38189510" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 22 Oct 2015 19:01:19 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9MJ1JmV003711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 19:01:19 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 14:00:59 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 14:00:59 -0500 From: "Carlos Pignataro (cpignata)" To: "int-dir@ietf.org" , "int-ads@ietf.org" Thread-Topic: Int-Dir - Review of draft-ietf-softwire-dslite-mib-11 Thread-Index: AQHRDPv8uQQq0547Q0u+jVdDMLjGGg== Date: Thu, 22 Oct 2015 19:00:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.54.194] Content-Type: multipart/signed; boundary="Apple-Mail=_CFC8D5B6-254A-40F7-8278-4B072F2FDBED"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-softwire-dslite-mib.all@ietf.org" Subject: [Int-dir] Int-Dir - Review of draft-ietf-softwire-dslite-mib-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 19:01:40 -0000 --Apple-Mail=_CFC8D5B6-254A-40F7-8278-4B072F2FDBED Content-Type: multipart/alternative; boundary="Apple-Mail=_0FB02800-92C3-473B-A824-B0E088E0987C" --Apple-Mail=_0FB02800-92C3-473B-A824-B0E088E0987C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I am an assigned INT directorate reviewer for = draft-ietf-softwire-dslite-mib-11. 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/intarea.html = . This document defines MIB objects to manage DS-Lite solutions, and = targets the Standards Track. Please find some minor review comments: 5. Difference from the IP tunnel MIB and NATV2-MIB Notes: According to section 5.2 of [RFC6333], DS-Lite only defines IPv4 in IPv6 tunnels at this moment, but other types of encapsulation could be defined in the future. So this DS-Lite MIB only supports IP in IP encapsulation, if another RFC defined other tunnel types in the future, this DS-Lite MIB will be updated then. CMP: Should the above say that this only supports IPv4-in-IPv6? The implementation of the IP Tunnel MIB is required for DS-Lite. The tunnelIfEncapsMethod in the tunnelIfEntry should be set to dsLite("xx"), and a corresponding entry in the DS-Lite module will exist for every tunnelIfEntry with this tunnelIfEncapsMethod. The tunnelIfRemoteInetAddress must be set to "::=E2=80=9D. CMP: Might be useful to add that this is because the tunnel is not = point-to-point. dsliteAFTRAlarmConnectNumber OBJECT-TYPE SYNTAX Integer32 (60..90) MAX-ACCESS read-write CMP: Has this been checked? = https://www.ietf.org/iesg/statement/writable-mib-module.html = 9. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. CMP: I only saw one read-write and no read-create. Are there =E2=80=9Ca = number of =E2=80=A6=E2=80=9D? 12.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . CMP: Why is RFC 2119 Informative? I hope these are useful! Thanks, =E2=80=94 Carlos. --Apple-Mail=_0FB02800-92C3-473B-A824-B0E088E0987C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I am = an assigned INT directorate reviewer for = draft-ietf-softwire-dslite-mib-11. 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/intarea.html.

This = document defines MIB objects to manage DS-Lite solutions, and targets = the Standards Track.

Please find some minor review comments:

5.  Difference from = the IP tunnel MIB and NATV2-MIB

   Notes: According = to section 5.2 of [RFC6333], DS-Lite only defines
   IPv4 in IPv6 tunnels at this moment, but other = types of encapsulation
   could be = defined in the future.  So this DS-Lite MIB only supports = IP
   in IP encapsulation, if another RFC = defined other tunnel types in the
  =  future, this DS-Lite MIB will be updated then.

CMP: Should the above = say that this only supports IPv4-in-IPv6?

   The = implementation of the IP Tunnel MIB is required for DS-Lite. =  The
   tunnelIfEncapsMethod in the = tunnelIfEntry should be set to
  =  dsLite("xx"), and a corresponding entry in the DS-Lite module = will
   exist for every tunnelIfEntry = with this tunnelIfEncapsMethod.  The
  =  tunnelIfRemoteInetAddress must be set to "::=E2=80=9D.

CMP: Might be useful = to add that this is because the tunnel is not point-to-point.

  =     dsliteAFTRAlarmConnectNumber OBJECT-TYPE
         SYNTAX Integer32 = (60..90)
        =  MAX-ACCESS read-write

CMP: Has this been checked? https://www.ietf.org/iesg/statement/writable-mib-module.html

9. =  Security Considerations

   There are a number of management objects defined = in this MIB module
   with a MAX-ACCESS = clause of read-write and/or read-create. 

CMP: I only saw one = read-write and no read-create. Are there =E2=80=9Ca number of = =E2=80=A6=E2=80=9D?

12.2.  Informative References

   [RFC2119] =  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement = Levels", BCP 14, RFC 2119,
    =           DOI 10.17487/RFC2119, March = 1997,
            =   <http://www.rfc-editor.org/info/rfc2119>.

CMP: Why is RFC 2119 = Informative?

I = hope these are useful!

Thanks,

=E2=80=94 Carlos.
= --Apple-Mail=_0FB02800-92C3-473B-A824-B0E088E0987C-- --Apple-Mail=_CFC8D5B6-254A-40F7-8278-4B072F2FDBED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWKTJ8AAoJEIXgpQGOZny9bu8P/jfVLBMlBPOe+L1Qn0+/kr5b dDRxVlq9VA1HrQxIefnmP/utQjiHaWZIjz6s+qidzCYpEMo3iFi/5KS4QtqEOyVx rHwL6T1Ly1FuxzL/zvoDHCWAnOWbn+QroZlXGchMWvQ03G+cvQexTzAq8CrXvUbb h4t2WxZz9ai7P/h3DRFnHoj7zrmDlgF0D2N9DeRisDhm+ItvHPzC9UrZUDM9Hlfj gXj+6Ps0niw+uQtYJ7HkAWGO7lv+sGW7V+SnbmwYR7fM8P+++val7NWQemHWaG3/ /o0w0wEf+RC8ervShO+KxtF3zKCVaXuCzEalUSoK7wfwBB6hR2gHmQm4fmGWG5fd GDygYQKmx4P9Gz+w0vd9iQWncG/iqqDShXv+G5T7bnI6+19ai82KiTjhUuHDEhOW DU2B0flDnq1Y/dFwdPCgVX6iAx2ERr4gusm7sTDaPnZc4JMxtSavYuq7Yc8ZfH/+ Zeb8XXsBYA+h1EHxeXWVvv/fLgTVt4rWMLmw20J8gT8mqluUp9bj2zcyV9uZTEzp O50QDsy93W+Dij8cyRk7EKwydLiOcuWlx5oOVRPqYgMOXALNBgtUY+NaVsPWAngo e6gBA30XB7vM/3872KKGqyeG/3nZHSBjis2Z0mJuPGzpEbz/hW8+un5shvhXPXL5 adP3eFCmHNIKoIH5CvId =QNES -----END PGP SIGNATURE----- --Apple-Mail=_CFC8D5B6-254A-40F7-8278-4B072F2FDBED-- From nobody Sat Oct 24 21:09:02 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785E61AC3C4; Sat, 24 Oct 2015 21:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WW9nOrWODaZ1; Sat, 24 Oct 2015 21:08:59 -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 A55B21AC3C3; Sat, 24 Oct 2015 21:08:56 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-07-562be8ef9d3f Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E9.4A.26730.FE8EB265; Sat, 24 Oct 2015 22:24:16 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Sun, 25 Oct 2015 00:08:54 -0400 From: Suresh Krishnan To: "Carlos Pignataro (cpignata)" , "int-dir@ietf.org" , "int-ads@ietf.org" Thread-Topic: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 Thread-Index: AQHRDPv6FKCF96/7CU+NxDHsiz8fgg== Date: Sun, 25 Oct 2015 04:08:53 +0000 Message-ID: References: <32E92224-BB99-4B2C-8138-8DDB4A6DC054@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPlO6HF9phBidPcVh8ereDxeLvoaPs Fp8Pnma0eHSlm8WBxWPK742sHkuW/GQKYIrisklJzcksSy3St0vgylh6/yxzwUrxilnXV7E2 MH4R6mLk5JAQMJF4fnwqI4QtJnHh3nq2LkYuDiGBo4wS25ddZIdwljNKTL50gwmkig2oY8PO z0wgCRGBNkaJD/t3sYMkmAViJZa3XQEbJSzgJXHkzVQWEFtEwFuief1eVghbT2LF6ktgg1gE VCUOfboLVs8r4CvxbfoUsDlCAjYSt1bcBoszAp30/dQaJoj54hK3nsxngjhVQGLJnvPMELao xMvH/1ghbCWJOa+vMUPUG0i8PzcfytaWWLbwNTPELkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKy gJFlFSNHaXFqWW66keEmRmCUHJNgc9zBuOCT5SFGAQ5GJR5ehePaYUKsiWXFlbmHGCU4mJVE eK1vAoV4UxIrq1KL8uOLSnNSiw8xSnOwKInzzptxP1RIID2xJDU7NbUgtQgmy8TBKdXAGHWD ycrsthtbmJvI9I2bBPZNKm4pPjhB3uBg6zGj1993sLx391Y0sN7B9Opzxk6hh54nBd/t+d3Q kv1DQNbL8UX9addbTgfy7oZU/FtWYVPK92hOkt+HqzWNx5hmbt3YYjNp79O4RA3r6zUvK2Y6 fjvnxKUlkJlx6/tLvhS3wvQn2u29r7ZdUGIpzkg01GIuKk4EACid2KSOAgAA Archived-At: Cc: "draft-ietf-softwire-mesh-mib.all@ietf.org" Subject: Re: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2015 04:09:01 -0000 Thanks for your review Carlos. Authors, can you please respond to this revi= ew.=0A= =0A= Regards=0A= Suresh=0A= =0A= On 10/22/2015 03:01 PM, Carlos Pignataro (cpignata) wrote:=0A= > Hi,=0A= >=0A= > I am an assigned INT directorate reviewer for=0A= > draft-ietf-softwire-mesh-mib-11. These comments were written primarily fo= r=0A= > the benefit of the Internet Area Directors. Document editors and shepherd= (s)=0A= > should treat these comments just like they would treat comments from any= =0A= > other IETF contributors and resolve them along with any other Last Call= =0A= > comments that have been received. For more details on the INT=0A= > Directorate, see http://www.ietf.org/iesg/directorate/intarea.html.=0A= >=0A= > This document defines MIB objects to manage softwire mesh solutions, and= =0A= > targets the Standards Track.=0A= >=0A= > I have a number of comments and concerns with this document, which amount= to=0A= > requesting the ADs to take a closer look:=0A= >=0A= > 3. Terminology=0A= >=0A= > This document uses terminology from the softwire problem statement=0A= > RFC 4925 [RFC4925] and the softwire mesh framework RFC 5565=0A= > [RFC5565].=0A= >=0A= > CMP: I think terminology from RFC 5512 is also heavily used.=0A= >=0A= > 5.1. The swmSupportedTunnelTable Subtree=0A= >=0A= > According=0A= > to section 4 of RFC 5512 [RFC5512], current softwire mesh tunnel=0A= > types include IP-IP, GRE and L2TPv3.=0A= >=0A= > CMP: This is true, but at the same time there are now many other =93curre= nt=0A= > tunnel types=94 (which are actually BGP Tunnel Encapsulation Attribute Tu= nnel=0A= > Types). See=0A= > http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunne= l-types Specifically=0A= > the ones introduced by RFC5566 ought to be included.=0A= >=0A= > CMP: This comment also applies to swmSupportedTunnelType=0A= >=0A= > XX. Missing sub-TLVs=0A= >=0A= > CMP: If the Tunnel Type is one which requires encapsulation information= =0A= > (e.g., L2TPv3 Session ID, Cookie, GRE Key, etc.), how is that information= =0A= > managed? I cannot seem to find it in the MIB Module. See Section 4.1 of R= FC 5512.=0A= >=0A= > CMP: Similarly, what about Protocol Type and Color (S4.2 and 4.3 of RFC= =0A= > 5512), and IPsec Tunnel Authenticator (RFC 5566)?=0A= >=0A= > CMP: Similarly, what about the Load-Balancing Block values from RFC 5640?= =0A= > Without this, an ECMP-aware L2TPv3 tunnel will be misunderstood.=0A= >=0A= > 8. Security Considerations=0A= >=0A= > The swmMIB module can be used for configuration of certain objects,= =0A= >=0A= > CMP: How is this so, without read-write or read-create?=0A= >=0A= > 11. References=0A= >=0A= > 11.1. Normative References=0A= >=0A= > CMP: Curiously, I do not see RFC 5566 or RFC 5640 referenced.=0A= >=0A= > Hope these help!=0A= >=0A= > Thanks,=0A= >=0A= > =97 Carlos.=0A= >=0A= =0A= From nobody Sun Oct 25 00:52:42 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67A51B2B46; Sun, 25 Oct 2015 00:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 DTzTN8sJCIez; Sun, 25 Oct 2015 00:52:40 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A5D1B2B45; Sun, 25 Oct 2015 00:52:36 -0700 (PDT) Received: by lffv3 with SMTP id v3so119359936lff.0; Sun, 25 Oct 2015 00:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vtZPu6XUCzk9XzVDyjZkycxVb8SPpRlgCok5fWKNxdU=; b=RN9pQZd0Ly0LC7XvXtx6senMEbe/Gk109K8nzfFdl5CDjMH5kj8od5lNOJg9feDhRm wGmHwKuzqq2GI1R5GgwaXKOGzmvvhTV823GsboOOYodSB4fTRyxa81XeNVnKVuzkSEhc 1JaZdHYHNT/aJp37fMsyd238Sb6pLwkermGOYEqjpD374F8nbzVbebaxcX1AiplZvSLf KbTSR7pL58t/VsyVu4S2mJplv9CBmfbpmiI8IJY4F4nMNqw0jeGHP8SN1uVK7G5dL5xV s1uB4oMmCvlVjjAeWRLji7O5N16C4ijssauA4IYr5Snb/NKTHm5oQ+pG59xwNlPwavMX DW/Q== MIME-Version: 1.0 X-Received: by 10.25.18.233 with SMTP id 102mr9392198lfs.96.1445759554717; Sun, 25 Oct 2015 00:52:34 -0700 (PDT) Received: by 10.25.23.160 with HTTP; Sun, 25 Oct 2015 00:52:34 -0700 (PDT) Date: Sun, 25 Oct 2015 15:52:34 +0800 Message-ID: From: Hui Deng To: int-dir@ietf.org, int-ads@ietf.org, draft-ietf-softwire-dslite-mib.all@ietf.org Content-Type: multipart/alternative; boundary=001a113fad6cb092bf0522e920cb Archived-At: Subject: [Int-dir] Int-Dir - Review of draft-ietf-softwire-dslite-mib-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2015 07:52:41 -0000 --001a113fad6cb092bf0522e920cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am an assigned INT directorate reviewer for draft-ietf-softwire-dslite-mib-11. 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/intarea.html. This document defines MIB objects to manage DS-Lite solutions, and targets the Standards Track. Please find some minor review comments: 1) As the coordination with the NATv2-MIB (the draft has not published), the MIB checker reports several errors in this DS-Lite MIB. 2) In section 6.1.1, =E2=80=9CBecause some objects defined in the IP Tunne= l MIB are not read-write and read-only, a few new objects are defined in DS- Lite MIB.=E2=80=9D What is the =E2=80=9Cread-write=E2=80=9D and =E2=80=9Cread-on= ly=E2=80=9D? If it is a special meaning words in MIB, it need a quotation mark here. 3) In page 8, =E2=80=9CdsliteTunnelAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION " This object MUST be set to the value of ipv6(2). It describes the address type of the IPv4-in-IPv6 tunnel initiator and endpoint." ::=3D { dsliteTunnelEntry 1 }=E2=80=9D There=E2=80=99s no scenario requiring ipv6z(4)? It needs a REFERENCE to RF= C 4001 in this object definition. 4) In page 10, DsliteNATBindEntry: I think dsliteNATBindMappingExtAddressType and dsliteNATBindMappingIntAddressType should just be dsliteNATBindMappingAddressType and apply to both. If all address objects in the row are of the same type, you only need one type object. 5) In page 11, it needs a REFERENCE to RFC 4001 in the definition of dsliteNATBindMappingExtPort. 6) In page 12, it need some description to describe =E2=80=9CendpointIndepe= ndent, addressDependent, addressAndPortDependent=E2=80=9D in more detail in the DESCRIPTION of dsliteNATBindMappingMapBehavior. The same comments to the =E2=80=9Carbitrary, paired=E2=80=9D in dsliteMATBindMappingAddressPooling. A REFERENCE is also needed. 7) In page 14, it needs to define a DEFVAL value for dsliteAFTRAlarmConnectionNumber. 8) Whether dsliteStatisticSubscriberIdex is enough or direct to get subscribers' information? 9) I am not very sure what is dsliteStatisticIpv6Session mean? As for IPv6 traffic, there seems no mapping. 10)Whether there has requirement to support multiple instances in DS-Lite? Best regards, DENG Hui --001a113fad6cb092bf0522e920cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I am an assigned INT dir= ectorate reviewer for draft-ietf-softwire-dslite-mib-11. These comments wer= e written primarily for the benefit of the Internet Area Directors.=C2=A0

Document editors and shepherd(s) should treat these= comments just like they would treat comments from any other IETF contribut= ors and resolve them along with any other=C2=A0

La= st Call comments that have been received. For more details on the INT Direc= torate, see h= ttp://www.ietf.org/iesg/directorate/intarea.html.

<= div>This document defines MIB objects to manage DS-Lite solutions, and targ= ets the Standards Track.

Please find some minor re= view comments:

1) As the coordination with the NAT= v2-MIB (the draft has not published), the MIB checker reports several error= s in this DS-Lite MIB.

2) In section 6.1.1, =C2=A0= =E2=80=9CBecause some objects defined in the IP Tunnel MIB are not read-wri= te and read-only, a few new objects are defined in DS- Lite MIB.=E2=80=9D W= hat is the =E2=80=9Cread-write=E2=80=9D and =E2=80=9Cread-only=E2=80=9D? If= it is a special meaning words in MIB, it need a quotation mark here.
=

3) In page 8,=C2=A0
=E2=80=9CdsliteTunnelAddr= essType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS n= ot-accessible
STATUS current
DESCRIPTION
&quo= t; This object MUST be set to the value of ipv6(2).
It describes = the address type of the IPv4-in-IPv6
tunnel initiator and endpoin= t."
::=3D { dsliteTunnelEntry 1 }=E2=80=9D

There=E2=80=99s no scenario requiring ipv6z(4)?=C2=A0 It needs a RE= FERENCE to RFC 4001 in this object definition.

4) In page 10, DsliteNATBindEntry: I think dsliteNATBindMapping= ExtAddressType and dsliteNATBindMappingIntAddressType should just be dslite= NATBindMappingAddressType and apply to both. If all address objects in the = row are of the same type, you only need one type object.

5) In page 11, it needs a REFERENCE to RFC 4001 in the definition of= dsliteNATBindMappingExtPort.

6) In page 12, it ne= ed some description to describe =E2=80=9CendpointIndependent, addressDepend= ent, addressAndPortDependent=E2=80=9D in more detail in the DESCRIPTION of = dsliteNATBindMappingMapBehavior.=C2=A0
=C2=A0The same comments to= the =E2=80=9Carbitrary, paired=E2=80=9D in dsliteMATBindMappingAddressPool= ing. A REFERENCE is also needed.

7) In page 14, it= needs to define a DEFVAL value for dsliteAFTRAlarmConnectionNumber.
<= /div>

8) Whether dsliteStatisticSubscriberIdex is enough or di= rect to get subscribers' information?=C2=A0

9)= I am not very sure what is dsliteStatisticIpv6Session mean? As for IPv6 tr= affic, there seems no mapping.=C2=A0

10)Whether th= ere has requirement to support multiple instances in DS-Lite?=C2=A0

Best regards,

DENG Hui
--001a113fad6cb092bf0522e920cb-- From nobody Sun Oct 25 00:55:31 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7B1B2B4B; Sun, 25 Oct 2015 00:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 tkE3gE-AQiMa; Sun, 25 Oct 2015 00:55:28 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC071B2B4D; Sun, 25 Oct 2015 00:55:28 -0700 (PDT) Received: by lffv3 with SMTP id v3so119385793lff.0; Sun, 25 Oct 2015 00:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NrKy4LP97a/bQ2lNcRcUnWE5UyPM7cYcZGjnS8wrc+g=; b=0JrS9SPp4rQnzk3xgIyWBMoLyDritJ1InUFiRPsO+pJXygH5I3tKuitnknbQhT+q+b B+NdzlVPw+jvPPyCc+0aFTVMvTj/NZxV3gqzAVTMAs10UZcGnld5TVAHD7yw/uGNmOJv e1LkIqM238VaXwLUREeyB8I2Kgm2KA4Y8jGJO2hJLWOSSe6O1w1+OFBoSqna2qv39AOD VY6xbVTTub5PJT9Sm0K3JMv49hZNtXAJcT8NiqSzNV5NHU3DzK1pR23RH0DQL207gj4g LIzPor5xkZjXITKpVvdt8Ml4bXNShS9mUzyBdD2XnRGcBAxYZsyVwTLeiMx2npJ/jvJg mrQg== MIME-Version: 1.0 X-Received: by 10.25.164.70 with SMTP id n67mr8012060lfe.24.1445759726485; Sun, 25 Oct 2015 00:55:26 -0700 (PDT) Received: by 10.25.23.160 with HTTP; Sun, 25 Oct 2015 00:55:26 -0700 (PDT) Date: Sun, 25 Oct 2015 15:55:26 +0800 Message-ID: From: Hui Deng To: int-dir@ietf.org, int-ads@ietf.org, draft-ietf-softwire-mesh-mib.all@ietf.org Content-Type: multipart/alternative; boundary=001a11402136ed8c7f0522e92ae7 Archived-At: Subject: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2015 07:55:30 -0000 --001a11402136ed8c7f0522e92ae7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I am an assigned INT directorate reviewer for draft-ietf-softwire-mesh-mib-11. 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/intarea.html. This document defines MIB objects to manage softwire mesh solutions, and targets the Standards Track. Please find below review comments: 1) Page 5 in section 6.2, =E2=80=9CThe tunnelIfRemoteInetAddress MUST be se= t to 0.0.0.0 for IPv4 or :: for IPv6 because it is a point to multi-point tunnel.=E2=80=9D It needs quotation mark for 0.0.0.0 and :: 2) In the MIB definitions, it needs REFERENCE for the IMPORT objects. eg: swmEncapsEIPDst OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The E-IP destination prefix, which is used for I-IP encapsulation destination looking up." ::=3D { swmEncapsEntry 2 } It should add a REFERENCE =E2=80=9CE-IP and I-IP in RFC 5565 =E2=80=9D. The= same comment for the definition of swmEncapsIIPDst. 3) In page 8, swmEncapsEIPDstType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies the address type used for swmEncapsEIPDst. It is different from the tunnelIfAddressType in the tunnelIfTable." ::=3D { swmEncapsEntry 1 } It should list ipv4(1) and ipv6(2) in the DESCRIPTION for different scenario. Also it should add a REFERENCE to RFC 4001. 4) In page 8, SwmEncapsEntry: I think swmEncapsEIPDstType and swmEncapsIIPDstType should just be swmEncapsIPDstType and apply to both. If all address objects in the row are of the same type, you only need one type object. 5) In page 7, =E2=80=9CRepresents the tunnel type that the AFBR supports=E2= =80=9D in definition of swmSupportedTunnelType. It need a clarification that It represents the tunnel type used for softwire mesh scenario. 6) As it states in the section 6.1, the ifInucastPkts counts the number of IPv6 packets which are sent to the virtual interface for decapsulation into IPv4. I think it need some statistics objects to define for the softwire mesh such as the number of the connection tunnel when running point to multi-point tunnel. 7) Why not define a parameter for swmEncapsIIPDstPrefixLength? 8) In the swmEncapsGroup, there are only information about swmEncapsIIPDst and swmEncapsIIPDstType, why there are not swmEncapsEIPDst and swmEncapsIIPType and so on? Best regards, DENG Hui --001a11402136ed8c7f0522e92ae7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

I am an assigned INT directorat= e reviewer for draft-ietf-softwire-mesh-mib-11. These comments were written= primarily for the benefit of the Internet Area Directors.=C2=A0
=
Document editors and shepherd(s) should treat these comments= just like they would treat comments from any other IETF contributors and r= esolve them along with any other=C2=A0

Last Call c= omments that have been received. For more details on the INT Directorate, s= ee http://www= .ietf.org/iesg/directorate/intarea.html.

This = document defines MIB objects to manage softwire mesh solutions, and targets= the Standards Track.

Please find below review com= ments:

1) Page 5 in section 6.2, =E2=80=9CThe tunnelIfRemoteInetAddress MUS= T be set to 0.0.0.0 for IPv4 or :: for IPv6 because it is a point to multi-= point tunnel.=E2=80=9D=C2=A0
It needs quotation mark for 0.0.0.0 = and ::

2) In the MIB definitions, it needs REFERENCE for the IMPORT objects= . eg:
swmEncapsEIPDst OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRI= PTION
"The E-IP destination prefix, which is
used = for I-IP encapsulation destination looking up."
::=3D { swmE= ncapsEntry 2 }

It should add a REFERENCE =E2=80=9C= E-IP and I-IP in RFC 5565 =E2=80=9D. The same comment for the definition of= swmEncapsIIPDst.

3) In page 8,=C2=A0
swmEncapsEIPDstType OBJECT-= TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object s= pecifies the address type used for
swmEncapsEIPDst. It is differe= nt from the tunnelIfAddressType
in the tunnelIfTable."
=
::=3D { swmEncapsEntry 1 }

It should list ipv= 4(1) and ipv6(2) in the DESCRIPTION for different scenario. Also it should = add a REFERENCE to RFC 4001.

4) In page 8, SwmEncapsEntry: I think swmEncap= sEIPDstType and swmEncapsIIPDstType should just be swmEncapsIPDstType and a= pply to both. If all address objects in=C2=A0

the = row are of the same type, you only need one type object.

5) In page 7, =E2= =80=9CRepresents the tunnel type that the AFBR supports=E2=80=9D in definit= ion of swmSupportedTunnelType. It need a clarification that It represents t= he tunnel=C2=A0

type used for softwire mesh scenar= io.

6) = As it states in the section 6.1, the ifInucastPkts counts the number= of IPv6 packets which are sent to the virtual interface for decapsulation = into IPv4. I=C2=A0

think it need some statistics o= bjects to define for the softwire mesh such as the number of the connection= tunnel when running point to multi-point tunnel.

= 7) Why not define a param= eter for swmEncapsIIPDstPrefixLength?=C2=A0

8) In the swmEncapsGroup, there= are only information about swmEncapsIIPDst and swmEncapsIIPDstType, why th= ere are not swmEncapsEIPDst and swmEncapsIIPType and so on?=C2=A0

Best regards,

DENG Hui
=
--001a11402136ed8c7f0522e92ae7-- From nobody Sun Oct 25 18:29:30 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FD31B3497; Sun, 25 Oct 2015 18:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 WPpIXPy1ukSv; Sun, 25 Oct 2015 18:29:26 -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 8C4981B3496; Sun, 25 Oct 2015 18:29:26 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-0d-562d1502e113 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F2.C2.26730.2051D265; Sun, 25 Oct 2015 18:44:34 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Sun, 25 Oct 2015 21:29:24 -0400 From: Suresh Krishnan To: Hui Deng , "int-dir@ietf.org" , "int-ads@ietf.org" , "draft-ietf-softwire-mesh-mib.all@ietf.org" Thread-Topic: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 Thread-Index: AQHRDvqHZwR+FH97H0uhQwkT0/Oz8A== Date: Mon, 26 Oct 2015 01:29:23 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXSPny6TqG6YwYJfMhY9S26xWfw9dJTd 4vPB04wWj650sziweOycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGccaZzIW9EpXHN0+n6mB cYZYFyMnh4SAicT12YeZIWwxiQv31rN1MXJxCAkcYZTY/mwXI0hCSGA5o0RvuwuIzQbUsGHn ZyaQIhGB84wSE9pPgRUJC3hJHHkzlQXEFhHwlmhev5cVwtaTeL13D9gGFgFVia97poHV8wr4 Spx7tYAFYkGAxPO7U9hAbEagK76fWsMEYjMLiEvcejKfCeI6AYkle85DXSoq8fLxP1YIW0li zutrzBD1BhLvz82HsrUlli18zQyxS1Di5MwnLBMYRWYhGTsLScssJC2zkLQsYGRZxchRWpxa lptuZLiJERgLxyTYHHcwLvhkeYhRgINRiYfXYJtOmBBrYllxZe4hRgkOZiUR3pnVumFCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEeefNuB8qJJCeWJKanZpakFoEk2Xi4JRqYJzgqLHiiYO3/2qh JbOn6PXdnvKjIuLvu/eXr8Tx+U1WNlonJrHoycJ9v7aZOL65e+Mwx/9JC5UsOHnlNuevPvDh 339JCUG1x8YBf3f55U/99T7ixxlO0//yHw9OKkgy3VKs41kqPjG/N/ie9bZiMSYDVdPFoX9f ruXuuHDcppPZ8lZTiKWr6z8lluKMREMt5qLiRAA6H658gQIAAA== Archived-At: Subject: Re: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 01:29:28 -0000 Thanks for your review Deng Hui. Authors, can you please respond to this = =0A= review and address the issues along with the ones raised in Carlos' Int Dir= =0A= review.=0A= =0A= Regards=0A= Suresh=0A= =0A= On 10/25/2015 03:55 AM, Hui Deng wrote:=0A= > Hi=0A= >=0A= > I am an assigned INT directorate reviewer for=0A= > draft-ietf-softwire-mesh-mib-11. These comments were written primarily fo= r=0A= > the benefit of the Internet Area Directors.=0A= >=0A= > Document editors and shepherd(s) should treat these comments just like th= ey=0A= > would treat comments from any other IETF contributors and resolve them al= ong=0A= > with any other=0A= >=0A= > Last Call comments that have been received. For more details on the INT= =0A= > Directorate, see http://www.ietf.org/iesg/directorate/intarea.html.=0A= >=0A= > This document defines MIB objects to manage softwire mesh solutions, and= =0A= > targets the Standards Track.=0A= >=0A= > Please find below review comments:=0A= >=0A= > 1)Page 5 in section 6.2, =93The tunnelIfRemoteInetAddress MUST be set to= =0A= > 0.0.0.0 for IPv4 or :: for IPv6 because it is a point to multi-point tunn= el.=94=0A= > It needs quotation mark for 0.0.0.0 and ::=0A= >=0A= > 2)In the MIB definitions, it needs REFERENCE for the IMPORT objects. eg:= =0A= > swmEncapsEIPDst OBJECT-TYPE=0A= > SYNTAX InetAddress=0A= > MAX-ACCESS not-accessible=0A= > STATUS current=0A= > DESCRIPTION=0A= > "The E-IP destination prefix, which is=0A= > used for I-IP encapsulation destination looking up."=0A= > ::=3D { swmEncapsEntry 2 }=0A= >=0A= > It should add a REFERENCE =93E-IP and I-IP in RFC 5565 =94. The same comm= ent for=0A= > the definition of swmEncapsIIPDst.=0A= >=0A= > 3)In page 8,=0A= > swmEncapsEIPDstType OBJECT-TYPE=0A= > SYNTAX InetAddressType=0A= > MAX-ACCESS not-accessible=0A= > STATUS current=0A= > DESCRIPTION=0A= > "This object specifies the address type used for=0A= > swmEncapsEIPDst. It is different from the tunnelIfAddressType=0A= > in the tunnelIfTable."=0A= > ::=3D { swmEncapsEntry 1 }=0A= >=0A= > It should list ipv4(1) and ipv6(2) in the DESCRIPTION for different scena= rio.=0A= > Also it should add a REFERENCE to RFC 4001.=0A= >=0A= > 4)In page 8, SwmEncapsEntry: I think swmEncapsEIPDstType and=0A= > swmEncapsIIPDstType should just be swmEncapsIPDstType and apply to both. = If=0A= > all address objects in=0A= >=0A= > the row are of the same type, you only need one type object.=0A= >=0A= > 5)In page 7, =93Represents the tunnel type that the AFBR supports=94 in= =0A= > definition of swmSupportedTunnelType. It need a clarification that It=0A= > represents the tunnel=0A= >=0A= > type used for softwire mesh scenario.=0A= >=0A= > 6)As it states in the section 6.1, the ifInucastPkts counts the number of= =0A= > IPv6 packets which are sent to the virtual interface for decapsulation in= to=0A= > IPv4. I=0A= >=0A= > think it need some statistics objects to define for the softwire mesh suc= h as=0A= > the number of the connection tunnel when running point to multi-point tun= nel.=0A= >=0A= > 7)Why not define a parameter for swmEncapsIIPDstPrefixLength?=0A= >=0A= > 8)In the swmEncapsGroup, there are only information about swmEncapsIIPDst= and=0A= > swmEncapsIIPDstType, why there are not swmEncapsEIPDst and swmEncapsIIPTy= pe=0A= > and so on?=0A= >=0A= > Best regards,=0A= >=0A= > DENG Hui=0A= =0A= From nobody Fri Oct 30 15:53:04 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97611B3235; Fri, 30 Oct 2015 15:53:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 OBt3u0z4X_Ow; Fri, 30 Oct 2015 15:52:58 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92011B31ED; Fri, 30 Oct 2015 15:52:57 -0700 (PDT) Received: by qkcl124 with SMTP id l124so33626302qkc.3; Fri, 30 Oct 2015 15:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version; bh=WoI6clBTHyEsjQvxKL3OodkIAspxgYXOh+pex1a7B8c=; b=P8SsSAlLgBBlrJPpdYZXH4Rid4XH8tofFJU3jZI8ZhGwBLpeEAkv79R9UmCPJj7oFv XDGOwMAP31MgbunbNMYdybJXoRhQHS9kkTwuxCCa3gj38nC4ImVpStqY/llY4u/5a+KL 09RbAifnFDqU/50z8fIrunnKIAL5I7/v3NHSi/NlNiQjmYH6M54DhhAynKEEpd4PbO+j RnPCdXBnhcL49KRoIM6gzP779Do8vbdUAccNWdCkiD2+lgZDm7GsTKftiIPhPVt/PGAp 9brBgC6Hf6HRclOMDC0+8N05V1rwBkw6AdnygvN0gDN7ET52scF4VO5fjJVjpgVFQZhT ecZA== X-Received: by 10.55.54.19 with SMTP id d19mr13619170qka.52.1446245576646; Fri, 30 Oct 2015 15:52:56 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1004::66? ([2001:420:c0c4:1004::66]) by smtp.gmail.com with ESMTPSA id f90sm3396237qgf.3.2015.10.30.15.52.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Oct 2015 15:52:56 -0700 (PDT) From: Ralph Droms X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_654404CF-A8AC-4F6D-B80F-43940D0399EC"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Sat, 31 Oct 2015 07:52:48 +0900 Message-Id: To: "" , draft-ietf-6tisch-minimal.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Int-dir] INT-DIR review of draft-ietf-6tisch-minimal-12 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 22:53:02 -0000 --Apple-Mail=_654404CF-A8AC-4F6D-B80F-43940D0399EC Content-Type: multipart/mixed; boundary="Apple-Mail=_42E06616-4D13-4BA5-BA45-6492B2178025" --Apple-Mail=_42E06616-4D13-4BA5-BA45-6492B2178025 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I am an assigned INT directorate reviewer for draft-ietf-6tisch-minimal-12. 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. Review submitted by Ralph Droms Summary: In my opinion, the WG needs to reconsider some of the fundamental aspects of this proposed specification, and the document needs significant restructuring and editing. I will be happy to work with the WG to revise the document and review future revisions. There may be overlaps between my comments and those in other reviews because I avoided reading those reviews before writing up my review. Here are my comments on the document. The first four comments apply to the document as a whole, while the remainder address more specific issues, roughly in the order of appearance in the document. 1. Goals and requirements are unclear The requirements for this document are unclear to me. Exactly what services would a "minimal mode of operation" provide? The Abstract and most of the document talks about the operation of an IEEE 802.15.4 TSCH network, yet the title of the document is "Minimal 6TiSCH Configuration". Does a network that follows these rules provide an L2 IEEE 802.15.4 service, an IPv6 6TiSCH service, ??? Related to this question, does this document describe "a minimal set of rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of operation" (both text snippets from the Abstract). 2. Requirement for RPL is ill-advised This document seems to be focused on IEEE 802.15.4 TSCH operational parameters. Yet, it calls for the use of RPL, which seems to me to be a highly undesirable entangling of protocols at different layers of the protocol stack. IEEE 802.15.4 TSCH is expected to be used in networks that don't use RPL. My understanding of the document is that RPL is assumed to be in use because it is required in a 6TiSCH network. RPL is then used to generate the Join Priority through the DAGRank function as specified in section 7.2. The use of RPL implies to me the configuration and operation of a full IPv6 stack, which hardly seems like a minimal mode of operation for IEEE 802.15.4 TSCH. I have a question about this text from section 7.2: When a node joins the network, it MUST NOT send EBs before having acquired a RPL rank. This avoids routing loops and matches RPL topology with underlying mesh topology. What is meant by "avoiding routing loops"? My understanding is that IEEE 802.15.4 TSCH simply provides for frame delivery between neighbors and does not provide frame forwarding. How would routing loops arise from running IEEE 802.15.4 TSCH? Has the WG considered reorganizing the 6TiSCH protocol suite and documents to separate the minimal operation of IEEE 802.15.4 TSCH from IPv6/RPL/ND/etc? For example, has the WG considered allowing a simpler, initial Join Priority scheme that would provide minimal IEEE 802.15.4 TSCH operation until the full IPv6 suite is running, at which time RPL will provide optimal routing. 3. Restatement of specifications in IEEE 802.15.4 documents I haven't read the most recent IEEE 802.15.4 docs and it has been a while since I took a close look at earlier revs. With that disclaimer in mind, how much of the text in sections 3 through 9 is a restatement of the IEEE 802.15.4 specification and how much is the specification of operational parameters for minimal operation of a IEEE 802.15.4 TSCH network? Restatement of specifications can be confusing and lead to a lack of interoperability. As a small example, here is section 6: 6. Acknowledgment Link-layer acknowledgment frames are built according to [IEEE802154]. Unicast frames sent to a unicast MAC destination address MUST request an acknowledgment. The sender node MUST set the ACK requested bit in the MAC header. The acknowledgment frame is of type ACK (frame type value 0b010). Each acknowledgment contains the following IE: ACK/NACK Time Correction IE: The ACK/NACK time correction IE carries the measured de-synchronization between the sender and the receiver. Refer to Section 11.3 for an example of the Header IE content. The possible values for the Time Synchronization Information and ACK status are described in [IEEE802154]. Out of that section, it seems to me that the first sentence is harmless, the second sentence is a specification for this document, the third and fourth sentences are a restatement of [IEEE802154] and the fifth sentence is an inferred specification for this document. The description of the IE is a restatement of [IEEE802154]. Section 6 could be rewritten as: 6. Acknowledgement frames Unicast frames sent to a unicast MAC destination address MUST request an acknowledgment. Each acknowledgment MUST contain an ACK/NACK Time Correction IE. 4. Default behavior versus learned behavior Which of the configuration and operational specifications in this document must be pre-configured before a node joins the network, and which are learned through, e.g., EBs. Are operational control and management questions out of scope for this document, such as: - when does a node switch from the "minimal 6TiSCH configuration" to some other configuration? - does a node use the configuration parameters it has received through EBs to generate its own EBs or does it use the "minimal 6TiSCH configuration" parameters? 5. In this text from the Introduction, does "synchronizes with the network" mean time synchronization or something else: [...] when a node synchronizes to the network. 6. I don't think the last sentence of the Introduction is relevant to an Introduction. 7. The document could use a section on the terminology used in the document, to provide definitive sources for definitions of the various terms and acronyms used in the document. Most likely, the terminology section would simply point to relevant sections of [IEEE802154] and [I-D.ietf-6tisch-terminology]. 8. Section 11 should be an Appendix, rather than part of the body of the document, so as to avoid making those examples normative standards text. 9. I think the contents of section 7.1 are entirely dependent on the specifics of an implementation and the section should be omitted. 10. I think the information in section 8 would be more generally useful if not stated in terms of a queue-based implementation: A node must not transmit frames containing higher-layer packets until the node has successfully joined a network. Frame types BEACON and ACK Frames generated by the IEEE 802.15.4 layer are transmitted before frames containing higher-layer packets. 11. According to [I-D.ietf-6tisch-terminology], the correct term is "timeslot", so s/time slot/timeslot/ throughout the document. 12. In the table at the top of page 4 (BTW, please number and add a title to all tables), are the listed properties the only properties that have numeric or short text string values? If not, all of those properties should be gathered together into a single table. As an editorial aside, this table is pretty much what I expected to be the bulk of this document. 13. Even if the number of timeslots in a slotframe is variable for this minimal configuration, should there be a default? 14. In the table at the top of page 5, what do the empty boxes represent? 15. The last sentence of section 3.2 seems to be a low-level implementation detail that can be omitted. 16. Without having read the IEEE 802.15.4 docs recently to confirm, I'll suggest that almost all of section 3.4 is a restatement of the IEEE 802.15.4 spec. The last sentence is important, and isn't entirely clear. It would be clearer to write: For the minimal configuration specified in this document, the use of CCA is OPTIONAL. 17. End of section 3 - not clear when to use macTimeslotTemplate. 18. The third paragraph of section 4 is completely unclear to me: A Node aiming to join the network by receving a properly formed BEACON shall enter in a scan phase and shall store the value of macPANId and then set it to 0xffff for the duration of the scan in order to meet the filtering rules in [IEEE802154]. What are "macPANId" and "scan phase"? I don't see those terms used anywhere else in this document; do the terms come from the IEEE 802.15.4 specs? Why would an implementation store the value of macPANId and then set it to 0xffff? 19. Does "synchronization" in section 5 mean "time synchronization"? 20. In section 5, is "EB_PERIOD" the same value as defined in the table in section 10.2.4 that defines "RPL-related variables"? If so, I don't understand why "EB_PERIOD" is in that table, as it only appears once in the rest of the document in section 5. 21. I see that section 10 includes the statement: Nodes in a multihop network MUST use the RPL routing protocol [RFC6550]. This statement is certainly false if one takes a broad definition of the word "multihop". Even if edited to "multilink subnet" or "mesh", I can't find any support in RFC 6550 for the statement "MUST use RPL routing protocol". I think it would be much clearer and more correct to quote verbatim the text describing this requirement from RFC 6550 rather than paraphrasing it here. Similarly, this sentence in section 10.1 needs, at least, to be edited, and I think it should be replaced with quoted text from RFC 6552. Nodes in the multihop network MUST implement the RPL Objective Function Zero [RFC6552]. While I haven't provided a detailed review of the remainder of section 10 because I don't think it's necessary for the goals of this document, it appears to me that much of section 10 is a restatement of the RPL specification from RFC 6550 and should, therefore, be omitted (if RPL is retained as a part of this recommendation). --Apple-Mail=_42E06616-4D13-4BA5-BA45-6492B2178025 Content-Disposition: attachment; filename=draft-ietf-6tisch-minimal-12_review.txt Content-Type: text/plain; name="draft-ietf-6tisch-minimal-12_review.txt" Content-Transfer-Encoding: 7bit I am an assigned INT directorate reviewer for draft-ietf-6tisch-minimal-12. 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. Review submitted by Ralph Droms Summary: In my opinion, the WG needs to reconsider some of the fundamental aspects of this proposed specification, and the document needs significant restructuring and editing. I will be happy to work with the WG to revise the document and review future revisions. There may be overlaps between my comments and those in other reviews because I avoided reading those reviews before writing up my review. Here are my comments on the document. The first four comments apply to the document as a whole, while the remainder address more specific issues, roughly in the order of appearance in the document. 1. Goals and requirements are unclear The requirements for this document are unclear to me. Exactly what services would a "minimal mode of operation" provide? The Abstract and most of the document talks about the operation of an IEEE 802.15.4 TSCH network, yet the title of the document is "Minimal 6TiSCH Configuration". Does a network that follows these rules provide an L2 IEEE 802.15.4 service, an IPv6 6TiSCH service, ??? Related to this question, does this document describe "a minimal set of rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of operation" (both text snippets from the Abstract). 2. Requirement for RPL is ill-advised This document seems to be focused on IEEE 802.15.4 TSCH operational parameters. Yet, it calls for the use of RPL, which seems to me to be a highly undesirable entangling of protocols at different layers of the protocol stack. IEEE 802.15.4 TSCH is expected to be used in networks that don't use RPL. My understanding of the document is that RPL is assumed to be in use because it is required in a 6TiSCH network. RPL is then used to generate the Join Priority through the DAGRank function as specified in section 7.2. The use of RPL implies to me the configuration and operation of a full IPv6 stack, which hardly seems like a minimal mode of operation for IEEE 802.15.4 TSCH. I have a question about this text from section 7.2: When a node joins the network, it MUST NOT send EBs before having acquired a RPL rank. This avoids routing loops and matches RPL topology with underlying mesh topology. What is meant by "avoiding routing loops"? My understanding is that IEEE 802.15.4 TSCH simply provides for frame delivery between neighbors and does not provide frame forwarding. How would routing loops arise from running IEEE 802.15.4 TSCH? Has the WG considered reorganizing the 6TiSCH protocol suite and documents to separate the minimal operation of IEEE 802.15.4 TSCH from IPv6/RPL/ND/etc? For example, has the WG considered allowing a simpler, initial Join Priority scheme that would provide minimal IEEE 802.15.4 TSCH operation until the full IPv6 suite is running, at which time RPL will provide optimal routing. 3. Restatement of specifications in IEEE 802.15.4 documents I haven't read the most recent IEEE 802.15.4 docs and it has been a while since I took a close look at earlier revs. With that disclaimer in mind, how much of the text in sections 3 through 9 is a restatement of the IEEE 802.15.4 specification and how much is the specification of operational parameters for minimal operation of a IEEE 802.15.4 TSCH network? Restatement of specifications can be confusing and lead to a lack of interoperability. As a small example, here is section 6: 6. Acknowledgment Link-layer acknowledgment frames are built according to [IEEE802154]. Unicast frames sent to a unicast MAC destination address MUST request an acknowledgment. The sender node MUST set the ACK requested bit in the MAC header. The acknowledgment frame is of type ACK (frame type value 0b010). Each acknowledgment contains the following IE: ACK/NACK Time Correction IE: The ACK/NACK time correction IE carries the measured de-synchronization between the sender and the receiver. Refer to Section 11.3 for an example of the Header IE content. The possible values for the Time Synchronization Information and ACK status are described in [IEEE802154]. Out of that section, it seems to me that the first sentence is harmless, the second sentence is a specification for this document, the third and fourth sentences are a restatement of [IEEE802154] and the fifth sentence is an inferred specification for this document. The description of the IE is a restatement of [IEEE802154]. Section 6 could be rewritten as: 6. Acknowledgement frames Unicast frames sent to a unicast MAC destination address MUST request an acknowledgment. Each acknowledgment MUST contain an ACK/NACK Time Correction IE. 4. Default behavior versus learned behavior Which of the configuration and operational specifications in this document must be pre-configured before a node joins the network, and which are learned through, e.g., EBs. Are operational control and management questions out of scope for this document, such as: - when does a node switch from the "minimal 6TiSCH configuration" to some other configuration? - does a node use the configuration parameters it has received through EBs to generate its own EBs or does it use the "minimal 6TiSCH configuration" parameters? 5. In this text from the Introduction, does "synchronizes with the network" mean time synchronization or something else: [...] when a node synchronizes to the network. 6. I don't think the last sentence of the Introduction is relevant to an Introduction. 7. The document could use a section on the terminology used in the document, to provide definitive sources for definitions of the various terms and acronyms used in the document. Most likely, the terminology section would simply point to relevant sections of [IEEE802154] and [I-D.ietf-6tisch-terminology]. 8. Section 11 should be an Appendix, rather than part of the body of the document, so as to avoid making those examples normative standards text. 9. I think the contents of section 7.1 are entirely dependent on the specifics of an implementation and the section should be omitted. 10. I think the information in section 8 would be more generally useful if not stated in terms of a queue-based implementation: A node must not transmit frames containing higher-layer packets until the node has successfully joined a network. Frame types BEACON and ACK Frames generated by the IEEE 802.15.4 layer are transmitted before frames containing higher-layer packets. 11. According to [I-D.ietf-6tisch-terminology], the correct term is "timeslot", so s/time slot/timeslot/ throughout the document. 12. In the table at the top of page 4 (BTW, please number and add a title to all tables), are the listed properties the only properties that have numeric or short text string values? If not, all of those properties should be gathered together into a single table. As an editorial aside, this table is pretty much what I expected to be the bulk of this document. 13. Even if the number of timeslots in a slotframe is variable for this minimal configuration, should there be a default? 14. In the table at the top of page 5, what do the empty boxes represent? 15. The last sentence of section 3.2 seems to be a low-level implementation detail that can be omitted. 16. Without having read the IEEE 802.15.4 docs recently to confirm, I'll suggest that almost all of section 3.4 is a restatement of the IEEE 802.15.4 spec. The last sentence is important, and isn't entirely clear. It would be clearer to write: For the minimal configuration specified in this document, the use of CCA is OPTIONAL. 17. End of section 3 - not clear when to use macTimeslotTemplate. 18. The third paragraph of section 4 is completely unclear to me: A Node aiming to join the network by receving a properly formed BEACON shall enter in a scan phase and shall store the value of macPANId and then set it to 0xffff for the duration of the scan in order to meet the filtering rules in [IEEE802154]. What are "macPANId" and "scan phase"? I don't see those terms used anywhere else in this document; do the terms come from the IEEE 802.15.4 specs? Why would an implementation store the value of macPANId and then set it to 0xffff? 19. Does "synchronization" in section 5 mean "time synchronization"? 20. In section 5, is "EB_PERIOD" the same value as defined in the table in section 10.2.4 that defines "RPL-related variables"? If so, I don't understand why "EB_PERIOD" is in that table, as it only appears once in the rest of the document in section 5. 21. I see that section 10 includes the statement: Nodes in a multihop network MUST use the RPL routing protocol [RFC6550]. This statement is certainly false if one takes a broad definition of the word "multihop". Even if edited to "multilink subnet" or "mesh", I can't find any support in RFC 6550 for the statement "MUST use RPL routing protocol". I think it would be much clearer and more correct to quote verbatim the text describing this requirement from RFC 6550 rather than paraphrasing it here. Similarly, this sentence in section 10.1 needs, at least, to be edited, and I think it should be replaced with quoted text from RFC 6552. Nodes in the multihop network MUST implement the RPL Objective Function Zero [RFC6552]. While I haven't provided a detailed review of the remainder of section 10 because I don't think it's necessary for the goals of this document, it appears to me that much of section 10 is a restatement of the RPL specification from RFC 6550 and should, therefore, be omitted (if RPL is retained as a part of this recommendation). --Apple-Mail=_42E06616-4D13-4BA5-BA45-6492B2178025 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_42E06616-4D13-4BA5-BA45-6492B2178025-- --Apple-Mail=_654404CF-A8AC-4F6D-B80F-43940D0399EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWM/TAAAoJEINeeBNmFjV5SIMP/R0BtFOUbs3HUgRihe02mhno NgY0wHddFERcoUE98FM6ntO9Lh0882l7OVMRtlK6omheiLQ9yN+4xDwS/owIaXTk V4SJCyRAQMdz56WkqgzOfAysVxwXriGTNUI7h0hmHTxozXerLvbibXes6ekZtKFS nG49Fq/vUR1IAWdnBXSuPsgcAR52z7w7ByIqTuQflvdIx4UDJgdeAsx2osYjhEV/ hRo0bTm3rt5ARAmzinR+5+RxHeIDsoYeekjpkI+X3DEW0O1712PL8goVPJibGPRN pYa7OPSSaK7RPsP5aCzeAKOL7qJS7KVal1iKIg58nZd+MKwmzx5JIgCF/db0k/Gg Mmgi7vRJnftLNYTLfb8MYQWi7hKmJifX6CSfpRNcF36KfKXkDzk06iUy+DrXHFjy 8/e/aZoK6OVNA85GSeHduk7+56mDP+kcBTTftp73OPYdYUOABAqcrF3Qb/Ix5zUt LJWlTWpy7kxkfym+pB2DFkBVJP+LUCsM02X30D7/GSeh2MEO/R0KvL8iPWLB7uey K1B0ROXXeSfS0ETafbcfTAx4S7oy1u6NgS51vqm/nMRxyLfdDWlQqdGTKggvBM6j KGxFiwl5ACyF7wgB8g5WmqRSHlVo1nKuW7g3dbwDNfmDhllr5SZXrjjMhUMRhdKH DjszZylWcyscv2zcdB4P =utJV -----END PGP SIGNATURE----- --Apple-Mail=_654404CF-A8AC-4F6D-B80F-43940D0399EC-- From nobody Fri Oct 30 16:49:29 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02D81B3C9F; Fri, 30 Oct 2015 16:49:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 inzPy8ZiANdE; Fri, 30 Oct 2015 16:49:21 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD4B1B3CA3; Fri, 30 Oct 2015 16:49:21 -0700 (PDT) Received: by qgbb65 with SMTP id b65so74454424qgb.2; Fri, 30 Oct 2015 16:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:message-id :references:to; bh=VH2PKgFeCF1krju90+YoUVrXO8P1PFDLzhawrDW2Gv8=; b=LaNcuDoesnZF4h51BsW3eAhjkZZS97P+87LSfmUtRMpBLPRRG5I1UYMPpVYI5cqK2A zD9BVt51+g11FJgGpRVjwcNJPiiK+Ovp1hVQUrkbuHBWsWL2Yq3LiaVamNmJN0Cw4H9i yqJdesjs8BLvzYMNorhyO/LPjwsuNzKfWHfNDGvqgDqziEMtgKw1/zanqKacf7B4k/Ux LqdcALlmfqIa+NSYgCmkCb3lKXU3aKOwXmOQTJxATEY4PdO3mq11DRNJZAWaQOrlQCss dNL/+363ioUFdnDCaDWHyu6RW0F47YWW16+uysywGQAtpQypXUM0ZgOF0DxIOCCGCmVG 1cBg== X-Received: by 10.140.156.18 with SMTP id c18mr14431684qhc.85.1446248960234; Fri, 30 Oct 2015 16:49:20 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1004::66? ([2001:420:c0c4:1004::66]) by smtp.gmail.com with ESMTPSA id r73sm3432816qha.48.2015.10.30.16.49.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Oct 2015 16:49:19 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A8E04A68-089B-4D0F-8117-DCDF67947DBB"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Pgp-Agent: GPGMail 2.5.2 From: Ralph Droms In-Reply-To: Date: Sat, 31 Oct 2015 08:49:12 +0900 Message-Id: References: To: "" , draft-ietf-6tisch-minimal.all@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Int-dir] INT-DIR review of draft-ietf-6tisch-minimal-12 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 23:49:27 -0000 --Apple-Mail=_A8E04A68-089B-4D0F-8117-DCDF67947DBB Content-Type: multipart/mixed; boundary="Apple-Mail=_C031FB3E-E79B-4641-B2EE-5EB934E8EB1C" --Apple-Mail=_C031FB3E-E79B-4641-B2EE-5EB934E8EB1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I just noticed I didn't complete the text for comment 10. Here is the = revised review. I am an assigned INT directorate reviewer for draft-ietf-6tisch-minimal-12. 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. Review submitted by Ralph Droms Summary: In my opinion, the WG needs to reconsider some of the fundamental aspects of this proposed specification, and the document needs significant restructuring and editing. I will be happy to work with the WG to revise the document and review future revisions. There may be overlaps between my comments and those in other reviews because I avoided reading those reviews before writing up my review. Here are my comments on the document. The first four comments apply to the document as a whole, while the remainder address more specific issues, roughly in the order of appearance in the document. 1. Goals and requirements are unclear The requirements for this document are unclear to me. Exactly what services would a "minimal mode of operation" provide? The Abstract and most of the document talks about the operation of an IEEE 802.15.4 TSCH network, yet the title of the document is "Minimal 6TiSCH Configuration". Does a network that follows these rules provide an L2 IEEE 802.15.4 service, an IPv6 6TiSCH service, ??? Related to this question, does this document describe "a minimal set of rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of operation" (both text snippets from the Abstract). 2. Requirement for RPL is ill-advised This document seems to be focused on IEEE 802.15.4 TSCH operational parameters. Yet, it calls for the use of RPL, which seems to me to be a highly undesirable entangling of protocols at different layers of the protocol stack. IEEE 802.15.4 TSCH is expected to be used in networks that don't use RPL. My understanding of the document is that RPL is assumed to be in use because it is required in a 6TiSCH network. RPL is then used to generate the Join Priority through the DAGRank function as specified in section 7.2. The use of RPL implies to me the configuration and operation of a full IPv6 stack, which hardly seems like a minimal mode of operation for IEEE 802.15.4 TSCH. I have a question about this text from section 7.2: When a node joins the network, it MUST NOT send EBs before having acquired a RPL rank. This avoids routing loops and matches RPL topology with underlying mesh topology. What is meant by "avoiding routing loops"? My understanding is that IEEE 802.15.4 TSCH simply provides for frame delivery between neighbors and does not provide frame forwarding. How would routing loops arise from running IEEE 802.15.4 TSCH? Has the WG considered reorganizing the 6TiSCH protocol suite and documents to separate the minimal operation of IEEE 802.15.4 TSCH from IPv6/RPL/ND/etc? For example, has the WG considered allowing a simpler, initial Join Priority scheme that would provide minimal IEEE 802.15.4 TSCH operation until the full IPv6 suite is running, at which time RPL will provide optimal routing. 3. Restatement of specifications in IEEE 802.15.4 documents I haven't read the most recent IEEE 802.15.4 docs and it has been a while since I took a close look at earlier revs. With that disclaimer in mind, how much of the text in sections 3 through 9 is a restatement of the IEEE 802.15.4 specification and how much is the specification of operational parameters for minimal operation of a IEEE 802.15.4 TSCH network? Restatement of specifications can be confusing and lead to a lack of interoperability. As a small example, here is section 6: 6. Acknowledgment Link-layer acknowledgment frames are built according to = [IEEE802154]. Unicast frames sent to a unicast MAC destination address MUST = request an acknowledgment. The sender node MUST set the ACK requested bit = in the MAC header. The acknowledgment frame is of type ACK (frame = type value 0b010). Each acknowledgment contains the following IE: ACK/NACK Time Correction IE: The ACK/NACK time correction IE carries the measured de-synchronization between the sender and = the receiver. Refer to Section 11.3 for an example of the Header IE content. The possible values for the Time Synchronization Information and ACK status are described in [IEEE802154]. Out of that section, it seems to me that the first sentence is harmless, the second sentence is a specification for this document, the third and fourth sentences are a restatement of [IEEE802154] and the fifth sentence is an inferred specification for this document. The description of the IE is a restatement of [IEEE802154]. Section 6 could be rewritten as: 6. Acknowledgement frames Unicast frames sent to a unicast MAC destination address MUST = request an acknowledgment. Each acknowledgment MUST contain an ACK/NACK Time Correction IE. 4. Default behavior versus learned behavior Which of the configuration and operational specifications in this document must be pre-configured before a node joins the network, and which are learned through, e.g., EBs. Are operational control and management questions out of scope for this document, such as: - when does a node switch from the "minimal 6TiSCH configuration" to some other configuration? - does a node use the configuration parameters it has received through EBs to generate its own EBs or does it use the "minimal 6TiSCH configuration" parameters? 5. In this text from the Introduction, does "synchronizes with the network" mean time synchronization or something else: [...] when a node synchronizes to the network. 6. I don't think the last sentence of the Introduction is relevant to an Introduction. 7. The document could use a section on the terminology used in the document, to provide definitive sources for definitions of the various terms and acronyms used in the document. Most likely, the terminology section would simply point to relevant sections of [IEEE802154] and [I-D.ietf-6tisch-terminology]. 8. Section 11 should be an Appendix, rather than part of the body of the document, so as to avoid making those examples normative standards text. 9. I think the contents of section 7.1 are entirely dependent on the specifics of an implementation and the section should be omitted. 10. I think the information in section 8 would be more generally useful if not stated in terms of a queue-based implementation: A node must not transmit frames containing higher-layer packets until the node has successfully joined a network. Frames generated by the IEEE 802.15.4 layer are transmitted before frames containing higher-layer packets. Frame types BEACON and COMMAND are transmitted before frame types DATA and ACK. A node has to be prepared to send a BEACON or COMMAND frame at any time. I've tried to infer the desired behavior from the description of queue usage. If I understand the original text correctly, there is no difference between the second and third requirements. 11. According to [I-D.ietf-6tisch-terminology], the correct term is "timeslot", so s/time slot/timeslot/ throughout the document. 12. In the table at the top of page 4 (BTW, please number and add a title to all tables), are the listed properties the only properties that have numeric or short text string values? If not, all of those properties should be gathered together into a single table. As an editorial aside, this table is pretty much what I expected to be the bulk of this document. 13. Even if the number of timeslots in a slotframe is variable for this minimal configuration, should there be a default? 14. In the table at the top of page 5, what do the empty boxes represent? 15. The last sentence of section 3.2 seems to be a low-level implementation detail that can be omitted. 16. Without having read the IEEE 802.15.4 docs recently to confirm, I'll suggest that almost all of section 3.4 is a restatement of the IEEE 802.15.4 spec. The last sentence is important, and isn't entirely clear. It would be clearer to write: For the minimal configuration specified in this document, the use of CCA is OPTIONAL. 17. End of section 3 - not clear when to use macTimeslotTemplate. 18. The third paragraph of section 4 is completely unclear to me: A Node aiming to join the network by receving a properly formed BEACON shall enter in a scan phase and shall store the value of macPANId and then set it to 0xffff for the duration of the scan in order to meet the filtering rules in [IEEE802154]. What are "macPANId" and "scan phase"? I don't see those terms used anywhere else in this document; do the terms come from the IEEE 802.15.4 specs? Why would an implementation store the value of macPANId and then set it to 0xffff? 19. Does "synchronization" in section 5 mean "time synchronization"? 20. In section 5, is "EB_PERIOD" the same value as defined in the table in section 10.2.4 that defines "RPL-related variables"? If so, I don't understand why "EB_PERIOD" is in that table, as it only appears once in the rest of the document in section 5. 21. I see that section 10 includes the statement: Nodes in a multihop network MUST use the RPL routing protocol [RFC6550]. This statement is certainly false if one takes a broad definition of the word "multihop". Even if edited to "multilink subnet" or "mesh", I can't find any support in RFC 6550 for the statement "MUST use RPL routing protocol". I think it would be much clearer and more correct to quote verbatim the text describing this requirement from RFC 6550 rather than paraphrasing it here. Similarly, this sentence in section 10.1 needs, at least, to be edited, and I think it should be replaced with quoted text from RFC 6552. Nodes in the multihop network MUST implement the RPL Objective Function Zero [RFC6552]. While I haven't provided a detailed review of the remainder of section 10 because I don't think it's necessary for the goals of this document, it appears to me that much of section 10 is a restatement of the RPL specification from RFC 6550 and should, therefore, be omitted (if RPL is retained as a part of this recommendation). --Apple-Mail=_C031FB3E-E79B-4641-B2EE-5EB934E8EB1C Content-Disposition: attachment; filename=draft-ietf-6tisch-minimal-12_review.txt Content-Type: text/plain; name="draft-ietf-6tisch-minimal-12_review.txt" Content-Transfer-Encoding: 7bit I am an assigned INT directorate reviewer for draft-ietf-6tisch-minimal-12. 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. Review submitted by Ralph Droms Summary: In my opinion, the WG needs to reconsider some of the fundamental aspects of this proposed specification, and the document needs significant restructuring and editing. I will be happy to work with the WG to revise the document and review future revisions. There may be overlaps between my comments and those in other reviews because I avoided reading those reviews before writing up my review. Here are my comments on the document. The first four comments apply to the document as a whole, while the remainder address more specific issues, roughly in the order of appearance in the document. 1. Goals and requirements are unclear The requirements for this document are unclear to me. Exactly what services would a "minimal mode of operation" provide? The Abstract and most of the document talks about the operation of an IEEE 802.15.4 TSCH network, yet the title of the document is "Minimal 6TiSCH Configuration". Does a network that follows these rules provide an L2 IEEE 802.15.4 service, an IPv6 6TiSCH service, ??? Related to this question, does this document describe "a minimal set of rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of operation" (both text snippets from the Abstract). 2. Requirement for RPL is ill-advised This document seems to be focused on IEEE 802.15.4 TSCH operational parameters. Yet, it calls for the use of RPL, which seems to me to be a highly undesirable entangling of protocols at different layers of the protocol stack. IEEE 802.15.4 TSCH is expected to be used in networks that don't use RPL. My understanding of the document is that RPL is assumed to be in use because it is required in a 6TiSCH network. RPL is then used to generate the Join Priority through the DAGRank function as specified in section 7.2. The use of RPL implies to me the configuration and operation of a full IPv6 stack, which hardly seems like a minimal mode of operation for IEEE 802.15.4 TSCH. I have a question about this text from section 7.2: When a node joins the network, it MUST NOT send EBs before having acquired a RPL rank. This avoids routing loops and matches RPL topology with underlying mesh topology. What is meant by "avoiding routing loops"? My understanding is that IEEE 802.15.4 TSCH simply provides for frame delivery between neighbors and does not provide frame forwarding. How would routing loops arise from running IEEE 802.15.4 TSCH? Has the WG considered reorganizing the 6TiSCH protocol suite and documents to separate the minimal operation of IEEE 802.15.4 TSCH from IPv6/RPL/ND/etc? For example, has the WG considered allowing a simpler, initial Join Priority scheme that would provide minimal IEEE 802.15.4 TSCH operation until the full IPv6 suite is running, at which time RPL will provide optimal routing. 3. Restatement of specifications in IEEE 802.15.4 documents I haven't read the most recent IEEE 802.15.4 docs and it has been a while since I took a close look at earlier revs. With that disclaimer in mind, how much of the text in sections 3 through 9 is a restatement of the IEEE 802.15.4 specification and how much is the specification of operational parameters for minimal operation of a IEEE 802.15.4 TSCH network? Restatement of specifications can be confusing and lead to a lack of interoperability. As a small example, here is section 6: 6. Acknowledgment Link-layer acknowledgment frames are built according to [IEEE802154]. Unicast frames sent to a unicast MAC destination address MUST request an acknowledgment. The sender node MUST set the ACK requested bit in the MAC header. The acknowledgment frame is of type ACK (frame type value 0b010). Each acknowledgment contains the following IE: ACK/NACK Time Correction IE: The ACK/NACK time correction IE carries the measured de-synchronization between the sender and the receiver. Refer to Section 11.3 for an example of the Header IE content. The possible values for the Time Synchronization Information and ACK status are described in [IEEE802154]. Out of that section, it seems to me that the first sentence is harmless, the second sentence is a specification for this document, the third and fourth sentences are a restatement of [IEEE802154] and the fifth sentence is an inferred specification for this document. The description of the IE is a restatement of [IEEE802154]. Section 6 could be rewritten as: 6. Acknowledgement frames Unicast frames sent to a unicast MAC destination address MUST request an acknowledgment. Each acknowledgment MUST contain an ACK/NACK Time Correction IE. 4. Default behavior versus learned behavior Which of the configuration and operational specifications in this document must be pre-configured before a node joins the network, and which are learned through, e.g., EBs. Are operational control and management questions out of scope for this document, such as: - when does a node switch from the "minimal 6TiSCH configuration" to some other configuration? - does a node use the configuration parameters it has received through EBs to generate its own EBs or does it use the "minimal 6TiSCH configuration" parameters? 5. In this text from the Introduction, does "synchronizes with the network" mean time synchronization or something else: [...] when a node synchronizes to the network. 6. I don't think the last sentence of the Introduction is relevant to an Introduction. 7. The document could use a section on the terminology used in the document, to provide definitive sources for definitions of the various terms and acronyms used in the document. Most likely, the terminology section would simply point to relevant sections of [IEEE802154] and [I-D.ietf-6tisch-terminology]. 8. Section 11 should be an Appendix, rather than part of the body of the document, so as to avoid making those examples normative standards text. 9. I think the contents of section 7.1 are entirely dependent on the specifics of an implementation and the section should be omitted. 10. I think the information in section 8 would be more generally useful if not stated in terms of a queue-based implementation: A node must not transmit frames containing higher-layer packets until the node has successfully joined a network. Frames generated by the IEEE 802.15.4 layer are transmitted before frames containing higher-layer packets. Frame types BEACON and COMMAND are transmitted before frame types DATA and ACK. A node has to be prepared to send a BEACON or COMMAND frame at any time. I've tried to infer the desired behavior from the description of queue usage. If I understand the original text correctly, there is no difference between the second and third requirements. 11. According to [I-D.ietf-6tisch-terminology], the correct term is "timeslot", so s/time slot/timeslot/ throughout the document. 12. In the table at the top of page 4 (BTW, please number and add a title to all tables), are the listed properties the only properties that have numeric or short text string values? If not, all of those properties should be gathered together into a single table. As an editorial aside, this table is pretty much what I expected to be the bulk of this document. 13. Even if the number of timeslots in a slotframe is variable for this minimal configuration, should there be a default? 14. In the table at the top of page 5, what do the empty boxes represent? 15. The last sentence of section 3.2 seems to be a low-level implementation detail that can be omitted. 16. Without having read the IEEE 802.15.4 docs recently to confirm, I'll suggest that almost all of section 3.4 is a restatement of the IEEE 802.15.4 spec. The last sentence is important, and isn't entirely clear. It would be clearer to write: For the minimal configuration specified in this document, the use of CCA is OPTIONAL. 17. End of section 3 - not clear when to use macTimeslotTemplate. 18. The third paragraph of section 4 is completely unclear to me: A Node aiming to join the network by receving a properly formed BEACON shall enter in a scan phase and shall store the value of macPANId and then set it to 0xffff for the duration of the scan in order to meet the filtering rules in [IEEE802154]. What are "macPANId" and "scan phase"? I don't see those terms used anywhere else in this document; do the terms come from the IEEE 802.15.4 specs? Why would an implementation store the value of macPANId and then set it to 0xffff? 19. Does "synchronization" in section 5 mean "time synchronization"? 20. In section 5, is "EB_PERIOD" the same value as defined in the table in section 10.2.4 that defines "RPL-related variables"? If so, I don't understand why "EB_PERIOD" is in that table, as it only appears once in the rest of the document in section 5. 21. I see that section 10 includes the statement: Nodes in a multihop network MUST use the RPL routing protocol [RFC6550]. This statement is certainly false if one takes a broad definition of the word "multihop". Even if edited to "multilink subnet" or "mesh", I can't find any support in RFC 6550 for the statement "MUST use RPL routing protocol". I think it would be much clearer and more correct to quote verbatim the text describing this requirement from RFC 6550 rather than paraphrasing it here. Similarly, this sentence in section 10.1 needs, at least, to be edited, and I think it should be replaced with quoted text from RFC 6552. Nodes in the multihop network MUST implement the RPL Objective Function Zero [RFC6552]. While I haven't provided a detailed review of the remainder of section 10 because I don't think it's necessary for the goals of this document, it appears to me that much of section 10 is a restatement of the RPL specification from RFC 6550 and should, therefore, be omitted (if RPL is retained as a part of this recommendation). --Apple-Mail=_C031FB3E-E79B-4641-B2EE-5EB934E8EB1C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_C031FB3E-E79B-4641-B2EE-5EB934E8EB1C-- --Apple-Mail=_A8E04A68-089B-4D0F-8117-DCDF67947DBB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWNAH5AAoJEINeeBNmFjV5C+EQAI+67CD/c6yxu6dEjYed9gcV VcnNlTGwCZJUCl8Avihq1DQ10vkXIpmN+cKb/ccFnMnjMZYh9sSGSr8+Rkx9eoIw C6EkIhHGNElRA/3ocb4zjx4XtoDEirCGl8ePRH/J/gufVIy+QpprJCcdlxBQTh71 5/tBROFctVSMb6hgHZCUZ818K+6VJKSvjBQx81QEAuUHENhAb3wjs5VUr3M7ovPw F6BrhevgkW0WmswLjCsIgIGTZAhcm/KaKHre7lnx15fidIQLQfwFTC5/c8GtCD/f blPguaGbPO54xxXbZ4xyEDJE7tVCww1Tu42PqG9Ts2DhjpbRQBET4EgYtPRP5sT+ tQvrNVy5REXR2qkOWeSd1TmLLZbUas9iz7ZWWGNn/qqF+fbJSPpVlp7D2pyvMvKh K9HiD49g/lK95HGbZhtWdmL7hF6zh80WBsKlegZfszhxihE+6ivKO/25PudsdyiJ 35z14hGqYOpJ79VP9Qe3a8hf/5fImn/BDADsNX/pNVYRo3MJPOxVmtNKvMLtKbbA qz5HE2paWlABUYEQ5txuArTxcopOuDJ1PCYSUEteI6o6L4e53l8e4mK9m8QI7PSb OSeF8DJJ3sV/f5NCVbvUeIyYUI8mjZWVq/jhm4uQ/OoLkvYO/odDvDWRscuKEKyo cYmKDKcv2cuBUJfOSNgd =jre0 -----END PGP SIGNATURE----- --Apple-Mail=_A8E04A68-089B-4D0F-8117-DCDF67947DBB-- From nobody Fri Oct 30 20:54:34 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81F21B29A8; Fri, 30 Oct 2015 20:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_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 FVYIkcqpeqH5; Fri, 30 Oct 2015 20:54:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491391B2850; Fri, 30 Oct 2015 20:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12301; q=dns/txt; s=iport; t=1446263667; x=1447473267; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/9AHgFV2aC6v8S3x2siQha7QlhlEPLKtedyuV3uGAQw=; b=ATjP3z/nM/v+ArE+FhusoCbiGZeeEe7s0O9nP3kt5jI+aqT0lxNtfEVE xQwfDM6HWjNTczMBcLCtgXXxpyMVP63pDdugpH3j8z3q95yFDEqlLDncL ZYXMUpIvsQy/xPmVpsTcqUMX3v0NIXt3b+/BY8FNlFIwSKRNQquJe9Yyq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKAgAOOTRW/5NdJa1egztTbwa/LQENgVohhXgCgTc4FAEBAQEBAQGBCoQ1AQEBBDotHgQCAQgOAwQBAR8JByERFAkIAgQBEggBiBIDEg2/CQ2EQgEBAQEBAQEBAQEBAQEBAQEBAQEBARiGd4R+gho5gj2EMAWWQwGIDIMigW+BYIQ/gySLLYNfg3EBHwEBQoQEcgGEdoEHAQEB X-IronPort-AV: E=Sophos;i="5.20,221,1444694400"; d="scan'208";a="42764374" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 31 Oct 2015 03:46:22 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9V3kMsQ012085 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 31 Oct 2015 03:46:22 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 30 Oct 2015 22:45:56 -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.1104.000; Fri, 30 Oct 2015 22:45:56 -0500 From: "Pascal Thubert (pthubert)" To: Ralph Droms , "" , "draft-ietf-6tisch-minimal.all@ietf.org" Thread-Topic: INT-DIR review of draft-ietf-6tisch-minimal-12 Thread-Index: AQHRE22PfZdoiK5D7UeMnr6pu10pG56E9MGg Date: Sat, 31 Oct 2015 03:45:33 +0000 Deferred-Delivery: Sat, 31 Oct 2015 03:45:28 +0000 Message-ID: References: In-Reply-To: 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.61.219.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Int-dir] INT-DIR review of draft-ietf-6tisch-minimal-12 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 03:54:32 -0000 Hello Ralph Regarding specifically your item 2, about RPL.=20 This may be related to your item 1 (clarity of the goal) but your comment = indicates that you missed the point of this draft. The point is to document a collection of protocols and settings that will e= nable to build a 6TiSCH mesh network and lead to interoperable implementati= ons. 6TiSCH defined that this minimal collection would include a TSCH MAC, IPv6,= 6LoWPAN and RPL. This makes full sense to me and in any fashion is the gro= up decision. Cheers, Pascal > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: samedi 31 octobre 2015 08:49 > To: ; draft-ietf-6tisch- > minimal.all@ietf.org > Subject: Re: INT-DIR review of draft-ietf-6tisch-minimal-12 >=20 > I just noticed I didn't complete the text for comment 10. Here is the re= vised > review. >=20 > I am an assigned INT directorate reviewer for draft-ietf-6tisch-minimal-1= 2. > These comments were written primarily for the benefit of the Internet Are= a > 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. >=20 > Review submitted by Ralph Droms >=20 > Summary: In my opinion, the WG needs to reconsider some of the > fundamental aspects of this proposed specification, and the document > needs significant restructuring and editing. I will be happy to work wit= h the > WG to revise the document and review future revisions. >=20 > There may be overlaps between my comments and those in other reviews > because I avoided reading those reviews before writing up my review. >=20 > Here are my comments on the document. The first four comments apply to > the document as a whole, while the remainder address more specific issues= , > roughly in the order of appearance in the document. >=20 > 1. Goals and requirements are unclear >=20 > The requirements for this document are unclear to me. Exactly what > services would a "minimal mode of operation" provide? The Abstract and > most of the document talks about the operation of an IEEE 802.15.4 TSCH > network, yet the title of the document is "Minimal 6TiSCH Configuration". > Does a network that follows these rules provide an L2 IEEE 802.15.4 servi= ce, > an IPv6 6TiSCH service, ??? >=20 > Related to this question, does this document describe "a minimal set of > rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of > operation" (both text snippets from the Abstract). >=20 > 2. Requirement for RPL is ill-advised >=20 > This document seems to be focused on IEEE 802.15.4 TSCH operational > parameters. Yet, it calls for the use of RPL, which seems to me to be a > highly undesirable entangling of protocols at different layers of the pro= tocol > stack. IEEE 802.15.4 TSCH is expected to be used in networks that don't = use > RPL. >=20 > My understanding of the document is that RPL is assumed to be in use > because it is required in a 6TiSCH network. RPL is then used to generate= the > Join Priority through the DAGRank function as specified in section 7.2. = The > use of RPL implies to me the configuration and operation of a full IPv6 > stack, which hardly seems like a minimal mode of operation for IEEE > 802.15.4 TSCH. >=20 > I have a question about this text from section 7.2: >=20 > When a node joins the network, > it MUST NOT send EBs before having acquired a RPL rank. This avoids > routing loops and matches RPL topology with underlying mesh topology. >=20 > What is meant by "avoiding routing loops"? My understanding is that IEEE > 802.15.4 TSCH simply provides for frame delivery between neighbors and > does not provide frame forwarding. How would routing loops arise from > running IEEE 802.15.4 TSCH? >=20 > Has the WG considered reorganizing the 6TiSCH protocol suite and > documents to separate the minimal operation of IEEE 802.15.4 TSCH from > IPv6/RPL/ND/etc? For example, has the WG considered allowing a simpler, > initial Join Priority scheme that would provide minimal IEEE > 802.15.4 TSCH operation until the full IPv6 suite is running, at which ti= me > RPL will provide optimal routing. >=20 > 3. Restatement of specifications in IEEE 802.15.4 documents >=20 > I haven't read the most recent IEEE 802.15.4 docs and it has been a while > since I took a close look at earlier revs. With that disclaimer in mind,= how > much of the text in sections 3 through 9 is a restatement of the IEEE > 802.15.4 specification and how much is the specification of operational > parameters for minimal operation of a IEEE 802.15.4 TSCH network? > Restatement of specifications can be confusing and lead to a lack of > interoperability. As a small example, here is section 6: >=20 > 6. Acknowledgment >=20 > Link-layer acknowledgment frames are built according to [IEEE802154]= . > Unicast frames sent to a unicast MAC destination address MUST reques= t > an acknowledgment. The sender node MUST set the ACK requested bit > in > the MAC header. The acknowledgment frame is of type ACK (frame type > value 0b010). Each acknowledgment contains the following IE: >=20 > ACK/NACK Time Correction IE: The ACK/NACK time correction IE > carries the measured de-synchronization between the sender and > the > receiver. Refer to Section 11.3 for an example of the Header IE > content. The possible values for the Time Synchronization > Information and ACK status are described in [IEEE802154]. >=20 > Out of that section, it seems to me that the first sentence is harmless, = the > second sentence is a specification for this document, the third and fourt= h > sentences are a restatement of [IEEE802154] and the fifth sentence is an > inferred specification for this document. The description of the IE is a > restatement of [IEEE802154]. >=20 > Section 6 could be rewritten as: >=20 > 6. Acknowledgement frames >=20 > Unicast frames sent to a unicast MAC destination address MUST reques= t > an acknowledgment. Each acknowledgment MUST contain an ACK/NACK > Time Correction IE. >=20 > 4. Default behavior versus learned behavior >=20 > Which of the configuration and operational specifications in this documen= t > must be pre-configured before a node joins the network, and which are > learned through, e.g., EBs. Are operational control and management > questions out of scope for this document, such as: >=20 > - when does a node switch from the "minimal 6TiSCH configuration" to > some other configuration? > - does a node use the configuration parameters it has received > through EBs to generate its own EBs or does it use the "minimal > 6TiSCH configuration" parameters? >=20 > 5. In this text from the Introduction, does "synchronizes with the networ= k" > mean time synchronization or something else: >=20 > [...] when a node synchronizes to the network. >=20 > 6. I don't think the last sentence of the Introduction is relevant to an > Introduction. >=20 > 7. The document could use a section on the terminology used in the > document, to provide definitive sources for definitions of the various te= rms > and acronyms used in the document. Most likely, the terminology section > would simply point to relevant sections of [IEEE802154] and [I-D.ietf-6ti= sch- > terminology]. >=20 > 8. Section 11 should be an Appendix, rather than part of the body of the > document, so as to avoid making those examples normative standards text. >=20 > 9. I think the contents of section 7.1 are entirely dependent on the spec= ifics > of an implementation and the section should be omitted. >=20 > 10. I think the information in section 8 would be more generally useful i= f > not stated in terms of a queue-based implementation: >=20 > A node must not transmit frames containing higher-layer packets > until the node has successfully joined a network. >=20 > Frames generated by the IEEE 802.15.4 layer are transmitted before > frames containing higher-layer packets. >=20 > Frame types BEACON and COMMAND are transmitted before frame types > DATA and ACK. >=20 > A node has to be prepared to send a BEACON or COMMAND frame at any > time. >=20 > I've tried to infer the desired behavior from the description of queue us= age. > If I understand the original text correctly, there is no difference betwe= en the > second and third requirements. >=20 > 11. According to [I-D.ietf-6tisch-terminology], the correct term is "time= slot", > so s/time slot/timeslot/ throughout the document. >=20 > 12. In the table at the top of page 4 (BTW, please number and add a title= to > all tables), are the listed properties the only properties that have nume= ric or > short text string values? If not, all of those properties should be gath= ered > together into a single table. As an editorial aside, this table is prett= y much > what I expected to be the bulk of this document. >=20 > 13. Even if the number of timeslots in a slotframe is variable for this > minimal configuration, should there be a default? >=20 > 14. In the table at the top of page 5, what do the empty boxes represent? >=20 > 15. The last sentence of section 3.2 seems to be a low-level implementati= on > detail that can be omitted. >=20 > 16. Without having read the IEEE 802.15.4 docs recently to confirm, I'll > suggest that almost all of section 3.4 is a restatement of the IEEE 802.1= 5.4 > spec. The last sentence is important, and isn't entirely clear. It woul= d be > clearer to write: >=20 > For the minimal configuration specified in this document, the use > of CCA is OPTIONAL. >=20 > 17. End of section 3 - not clear when to use macTimeslotTemplate. >=20 > 18. The third paragraph of section 4 is completely unclear to me: >=20 > A Node aiming to join the network by receving a properly formed > BEACON shall enter in a scan phase and shall store the value of > macPANId and then set it to 0xffff for the duration of the scan in > order to meet the filtering rules in [IEEE802154]. >=20 > What are "macPANId" and "scan phase"? I don't see those terms used > anywhere else in this document; do the terms come from the IEEE > 802.15.4 specs? Why would an implementation store the value of > macPANId and then set it to 0xffff? >=20 > 19. Does "synchronization" in section 5 mean "time synchronization"? >=20 > 20. In section 5, is "EB_PERIOD" the same value as defined in the table i= n > section 10.2.4 that defines "RPL-related variables"? If so, I don't > understand why "EB_PERIOD" is in that table, as it only appears once in t= he > rest of the document in section 5. >=20 > 21. I see that section 10 includes the statement: >=20 > Nodes in a multihop network MUST use the RPL routing protocol > [RFC6550]. >=20 > This statement is certainly false if one takes a broad definition of the = word > "multihop". Even if edited to "multilink subnet" or "mesh", I can't find= any > support in RFC 6550 for the statement "MUST use RPL routing protocol". I > think it would be much clearer and more correct to quote verbatim the tex= t > describing this requirement from RFC 6550 rather than paraphrasing it > here. >=20 > Similarly, this sentence in section 10.1 needs, at least, to be edited, a= nd I > think it should be replaced with quoted text from RFC 6552. >=20 > Nodes in the multihop network MUST implement the RPL Objective > Function Zero [RFC6552]. >=20 > While I haven't provided a detailed review of the remainder of section > 10 because I don't think it's necessary for the goals of this document, i= t > appears to me that much of section 10 is a restatement of the RPL > specification from RFC 6550 and should, therefore, be omitted (if RPL is > retained as a part of this recommendation). From nobody Fri Oct 30 21:25:00 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CB81B2F3F; Fri, 30 Oct 2015 21:24:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 FPblwYU1Q06o; Fri, 30 Oct 2015 21:24:55 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3761A1B2F3C; Fri, 30 Oct 2015 21:24:55 -0700 (PDT) Received: by qgbb65 with SMTP id b65so77484930qgb.2; Fri, 30 Oct 2015 21:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=IhZDtkEr4/utZgtehK4pOUCzeJbLJNxGiyS42XOM+Ss=; b=rMykG2PCpe6x8bvnNFdsCmedKcaEAxvd1Rv68b0D7vVl4D1BrcbS33v2u4uqQFoTz3 h7J2hWU7NhH/q9avYkQbaPi/p+4YYOkrhfjMh4sgtzajyGruhtlDhqobyduJFPwypfBC Qoz3y4iiAWMH0FeHFVU4Ond3qW49dMG1cVlTwAHKOi7mb4wYKQ16Gn4quRcNSX73zky/ b3SJMpRZmqMFbK9i7YvGgnQ/IIzYPfVNtathEum5bxhBEYzCS2T4ZGpFiRyiTnBoNsoH B6dVK5+UU/drNoamHG2tAMq55kxmm9ZX9xX7R9k5WWH28uQI52rDP3WtWEmURRWJO6xj DBVw== X-Received: by 10.140.100.240 with SMTP id s103mr14280880qge.25.1446265494416; Fri, 30 Oct 2015 21:24:54 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1004::32? ([2001:420:c0c4:1004::32]) by smtp.gmail.com with ESMTPSA id z66sm2631624qka.13.2015.10.30.21.24.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Oct 2015 21:24:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9F0256C7-BC1F-4411-841E-29DE3DC770D7"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Ralph Droms In-Reply-To: Date: Sat, 31 Oct 2015 13:24:41 +0900 Message-Id: <20A7A202-73D1-4071-9AC4-5E06ED10FF5D@gmail.com> References: To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-ietf-6tisch-minimal.all@ietf.org" , "" Subject: Re: [Int-dir] INT-DIR review of draft-ietf-6tisch-minimal-12 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 04:24:59 -0000 --Apple-Mail=_9F0256C7-BC1F-4411-841E-29DE3DC770D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 31, 2015, at 12:45 PM 10/31/15, Pascal Thubert (pthubert) = wrote: >=20 > Hello Ralph >=20 > Regarding specifically your item 2, about RPL. >=20 > This may be related to your item 1 (clarity of the goal) but your = comment indicates that you missed the point of this draft. >=20 > The point is to document a collection of protocols and settings that = will enable to build a 6TiSCH mesh network and lead to interoperable = implementations. OK, but the first sentence of the abstract is: This document describes the minimal set of rules to operate an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network. The *only* occurrence of the string "6tisch" (case insensitive) in the = text of this document (not in citations, etc.) is in the Acknowledgments = section: Also our acknowledge to the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne for their guideance and advice. How in the world would anyone know this document is intended to cover = the entire stack as required by a "6TiSCH mesh network". > 6TiSCH defined that this minimal collection would include a TSCH MAC, = IPv6, 6LoWPAN and RPL. This makes full sense to me and in any fashion is = the group decision. I didn't say it wasn't a group decision ... I disagree with the group = decision, as I understood the purpose of this document from the = Abstract. If this document is really supposed to describe the minimal requirements = for the whole stack in a "6TiSCH mesh network", doesn't it need text = describing address assignment, which flavor and how to use ND, etc., = etc. - Ralph >=20 > Cheers, >=20 > Pascal >=20 >> -----Original Message----- >> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] >> Sent: samedi 31 octobre 2015 08:49 >> To: ; draft-ietf-6tisch- >> minimal.all@ietf.org >> Subject: Re: INT-DIR review of draft-ietf-6tisch-minimal-12 >>=20 >> I just noticed I didn't complete the text for comment 10. Here is = the revised >> review. >>=20 >> I am an assigned INT directorate reviewer for = draft-ietf-6tisch-minimal-12. >> 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. >>=20 >> Review submitted by Ralph Droms >>=20 >> Summary: In my opinion, the WG needs to reconsider some of the >> fundamental aspects of this proposed specification, and the document >> needs significant restructuring and editing. I will be happy to work = with the >> WG to revise the document and review future revisions. >>=20 >> There may be overlaps between my comments and those in other reviews >> because I avoided reading those reviews before writing up my review. >>=20 >> Here are my comments on the document. The first four comments apply = to >> the document as a whole, while the remainder address more specific = issues, >> roughly in the order of appearance in the document. >>=20 >> 1. Goals and requirements are unclear >>=20 >> The requirements for this document are unclear to me. Exactly what >> services would a "minimal mode of operation" provide? The Abstract = and >> most of the document talks about the operation of an IEEE 802.15.4 = TSCH >> network, yet the title of the document is "Minimal 6TiSCH = Configuration". >> Does a network that follows these rules provide an L2 IEEE 802.15.4 = service, >> an IPv6 6TiSCH service, ??? >>=20 >> Related to this question, does this document describe "a minimal set = of >> rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal = mode of >> operation" (both text snippets from the Abstract). >>=20 >> 2. Requirement for RPL is ill-advised >>=20 >> This document seems to be focused on IEEE 802.15.4 TSCH operational >> parameters. Yet, it calls for the use of RPL, which seems to me to = be a >> highly undesirable entangling of protocols at different layers of the = protocol >> stack. IEEE 802.15.4 TSCH is expected to be used in networks that = don't use >> RPL. >>=20 >> My understanding of the document is that RPL is assumed to be in use >> because it is required in a 6TiSCH network. RPL is then used to = generate the >> Join Priority through the DAGRank function as specified in section = 7.2. The >> use of RPL implies to me the configuration and operation of a full = IPv6 >> stack, which hardly seems like a minimal mode of operation for IEEE >> 802.15.4 TSCH. >>=20 >> I have a question about this text from section 7.2: >>=20 >> When a node joins the network, >> it MUST NOT send EBs before having acquired a RPL rank. This = avoids >> routing loops and matches RPL topology with underlying mesh = topology. >>=20 >> What is meant by "avoiding routing loops"? My understanding is that = IEEE >> 802.15.4 TSCH simply provides for frame delivery between neighbors = and >> does not provide frame forwarding. How would routing loops arise = from >> running IEEE 802.15.4 TSCH? >>=20 >> Has the WG considered reorganizing the 6TiSCH protocol suite and >> documents to separate the minimal operation of IEEE 802.15.4 TSCH = from >> IPv6/RPL/ND/etc? For example, has the WG considered allowing a = simpler, >> initial Join Priority scheme that would provide minimal IEEE >> 802.15.4 TSCH operation until the full IPv6 suite is running, at = which time >> RPL will provide optimal routing. >>=20 >> 3. Restatement of specifications in IEEE 802.15.4 documents >>=20 >> I haven't read the most recent IEEE 802.15.4 docs and it has been a = while >> since I took a close look at earlier revs. With that disclaimer in = mind, how >> much of the text in sections 3 through 9 is a restatement of the IEEE >> 802.15.4 specification and how much is the specification of = operational >> parameters for minimal operation of a IEEE 802.15.4 TSCH network? >> Restatement of specifications can be confusing and lead to a lack of >> interoperability. As a small example, here is section 6: >>=20 >> 6. Acknowledgment >>=20 >> Link-layer acknowledgment frames are built according to = [IEEE802154]. >> Unicast frames sent to a unicast MAC destination address MUST = request >> an acknowledgment. The sender node MUST set the ACK requested = bit >> in >> the MAC header. The acknowledgment frame is of type ACK (frame = type >> value 0b010). Each acknowledgment contains the following IE: >>=20 >> ACK/NACK Time Correction IE: The ACK/NACK time correction IE >> carries the measured de-synchronization between the sender and >> the >> receiver. Refer to Section 11.3 for an example of the Header IE >> content. The possible values for the Time Synchronization >> Information and ACK status are described in [IEEE802154]. >>=20 >> Out of that section, it seems to me that the first sentence is = harmless, the >> second sentence is a specification for this document, the third and = fourth >> sentences are a restatement of [IEEE802154] and the fifth sentence is = an >> inferred specification for this document. The description of the IE = is a >> restatement of [IEEE802154]. >>=20 >> Section 6 could be rewritten as: >>=20 >> 6. Acknowledgement frames >>=20 >> Unicast frames sent to a unicast MAC destination address MUST = request >> an acknowledgment. Each acknowledgment MUST contain an ACK/NACK >> Time Correction IE. >>=20 >> 4. Default behavior versus learned behavior >>=20 >> Which of the configuration and operational specifications in this = document >> must be pre-configured before a node joins the network, and which are >> learned through, e.g., EBs. Are operational control and management >> questions out of scope for this document, such as: >>=20 >> - when does a node switch from the "minimal 6TiSCH configuration" to >> some other configuration? >> - does a node use the configuration parameters it has received >> through EBs to generate its own EBs or does it use the "minimal >> 6TiSCH configuration" parameters? >>=20 >> 5. In this text from the Introduction, does "synchronizes with the = network" >> mean time synchronization or something else: >>=20 >> [...] when a node synchronizes to the network. >>=20 >> 6. I don't think the last sentence of the Introduction is relevant to = an >> Introduction. >>=20 >> 7. The document could use a section on the terminology used in the >> document, to provide definitive sources for definitions of the = various terms >> and acronyms used in the document. Most likely, the terminology = section >> would simply point to relevant sections of [IEEE802154] and = [I-D.ietf-6tisch- >> terminology]. >>=20 >> 8. Section 11 should be an Appendix, rather than part of the body of = the >> document, so as to avoid making those examples normative standards = text. >>=20 >> 9. I think the contents of section 7.1 are entirely dependent on the = specifics >> of an implementation and the section should be omitted. >>=20 >> 10. I think the information in section 8 would be more generally = useful if >> not stated in terms of a queue-based implementation: >>=20 >> A node must not transmit frames containing higher-layer packets >> until the node has successfully joined a network. >>=20 >> Frames generated by the IEEE 802.15.4 layer are transmitted before >> frames containing higher-layer packets. >>=20 >> Frame types BEACON and COMMAND are transmitted before frame types >> DATA and ACK. >>=20 >> A node has to be prepared to send a BEACON or COMMAND frame at any >> time. >>=20 >> I've tried to infer the desired behavior from the description of = queue usage. >> If I understand the original text correctly, there is no difference = between the >> second and third requirements. >>=20 >> 11. According to [I-D.ietf-6tisch-terminology], the correct term is = "timeslot", >> so s/time slot/timeslot/ throughout the document. >>=20 >> 12. In the table at the top of page 4 (BTW, please number and add a = title to >> all tables), are the listed properties the only properties that have = numeric or >> short text string values? If not, all of those properties should be = gathered >> together into a single table. As an editorial aside, this table is = pretty much >> what I expected to be the bulk of this document. >>=20 >> 13. Even if the number of timeslots in a slotframe is variable for = this >> minimal configuration, should there be a default? >>=20 >> 14. In the table at the top of page 5, what do the empty boxes = represent? >>=20 >> 15. The last sentence of section 3.2 seems to be a low-level = implementation >> detail that can be omitted. >>=20 >> 16. Without having read the IEEE 802.15.4 docs recently to confirm, = I'll >> suggest that almost all of section 3.4 is a restatement of the IEEE = 802.15.4 >> spec. The last sentence is important, and isn't entirely clear. It = would be >> clearer to write: >>=20 >> For the minimal configuration specified in this document, the use >> of CCA is OPTIONAL. >>=20 >> 17. End of section 3 - not clear when to use macTimeslotTemplate. >>=20 >> 18. The third paragraph of section 4 is completely unclear to me: >>=20 >> A Node aiming to join the network by receving a properly formed >> BEACON shall enter in a scan phase and shall store the value of >> macPANId and then set it to 0xffff for the duration of the scan in >> order to meet the filtering rules in [IEEE802154]. >>=20 >> What are "macPANId" and "scan phase"? I don't see those terms used >> anywhere else in this document; do the terms come from the IEEE >> 802.15.4 specs? Why would an implementation store the value of >> macPANId and then set it to 0xffff? >>=20 >> 19. Does "synchronization" in section 5 mean "time synchronization"? >>=20 >> 20. In section 5, is "EB_PERIOD" the same value as defined in the = table in >> section 10.2.4 that defines "RPL-related variables"? If so, I don't >> understand why "EB_PERIOD" is in that table, as it only appears once = in the >> rest of the document in section 5. >>=20 >> 21. I see that section 10 includes the statement: >>=20 >> Nodes in a multihop network MUST use the RPL routing protocol >> [RFC6550]. >>=20 >> This statement is certainly false if one takes a broad definition of = the word >> "multihop". Even if edited to "multilink subnet" or "mesh", I can't = find any >> support in RFC 6550 for the statement "MUST use RPL routing = protocol". I >> think it would be much clearer and more correct to quote verbatim the = text >> describing this requirement from RFC 6550 rather than paraphrasing it >> here. >>=20 >> Similarly, this sentence in section 10.1 needs, at least, to be = edited, and I >> think it should be replaced with quoted text from RFC 6552. >>=20 >> Nodes in the multihop network MUST implement the RPL Objective >> Function Zero [RFC6552]. >>=20 >> While I haven't provided a detailed review of the remainder of = section >> 10 because I don't think it's necessary for the goals of this = document, it >> appears to me that much of section 10 is a restatement of the RPL >> specification from RFC 6550 and should, therefore, be omitted (if RPL = is >> retained as a part of this recommendation). >=20 --Apple-Mail=_9F0256C7-BC1F-4411-841E-29DE3DC770D7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWNEKKAAoJEINeeBNmFjV5qgQQALrKfpHdYtXINNEh9vEwi9vJ TNhLS2bsN0K4kSgHDlOlhgxZhxLZtJ8wSEbKjtzp6gTUfM+okp6NgOY8DSUJRU/+ wsjh/JwZDk2nBh/g0dJzQqvzfsX21Y1G9+J4AgSPP4jrvZR/yzXHfC8Yo7r1S0s3 arVN/UEbeegrIA7GGUuvdJoPtjK2qGC3pVj34WvAH1eLv7ti4M9mxnTta2Uv/vr/ +gnlc4n4iK6DblRgir0sjtIjLsCCKeF8MvGuHOnFyPoVBCuHmkif1Hb93TRl1akb rYw1fcic5I63wSuQufgBREplPLhGFL8WZS0esrzu9vAuUr19ArFksGN7gj/y9XcQ OUiG8euwwXwNbKlLxvRzn+mZl8y711zU0SGmIXHUJiHnCCK0k1WXcv1iwf6ieKsy l8V3GjTMBZw8dtJ5ER8898sj/xBsFRJjoAPU6u2TbsB2Ymhk5bbFfc2EIB2QFcIK Tzd8GTbflDiNYLAPA4re+hL7VEeNCgayc5bHCjeE3l8dCd2oyit89YYxbfJn5VuE tOVW9EZHw/4XaEf+6w24FQlun8DbO6D/lHseSxipVX+AIXULfJCqdzCFkg5vUmsg ygA1mAizm0klHUtHk9PcJsjaVpPecEoFI2g3baHzFC4N7QVhnggk9eE6A/ooCvnP IgQxBECxNj9lMvq5Sp6K =tEgT -----END PGP SIGNATURE----- --Apple-Mail=_9F0256C7-BC1F-4411-841E-29DE3DC770D7-- From nobody Sat Oct 31 03:01:05 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55251B3665; Sat, 31 Oct 2015 03:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_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 Cft_6xJ-hapl; Sat, 31 Oct 2015 03:01:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE4D1B3664; Sat, 31 Oct 2015 03:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14707; q=dns/txt; s=iport; t=1446285660; x=1447495260; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cu94brcuhXoCximjQII68B+XYgIAvnEpdV5FdDb5h3M=; b=eoRIP3aJokjBnfmSeyXi2pmpO3MoJ32cGRUGi40+xbRyq9lT10gteDXf g3MSJAOj7U0oKViNpV9iClPmsl5tEncO2//zkmbFqnOydqD4nI8uVu0mP Yqk5vGNmjfqMjcHFrSOqO59S5xWZFdz1kBaEAHEvVU+CDRa5ogXSiK/86 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgC2kDRW/4UNJK1egztTbwa/LwENg?= =?us-ascii?q?VohhXgCgSU4FAEBAQEBAQGBCoQ1AQEBAwE6LRIMBAIBCA4DAQMBAQEeCQchERQ?= =?us-ascii?q?DBggCBA4FCAGIEgMKCA2+ZQ2EQgEBAQEBAQEBAQEBAQEBAQEBAQEBARiGd4R+g?= =?us-ascii?q?lOCPYQwBZZDAYgMgyKBb4FghD+DJIstg1+DcQEfAQFChARyAYR2gQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,223,1444694400"; d="scan'208";a="203169694" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Oct 2015 10:00:58 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9VA0wSm030328 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 31 Oct 2015 10:00:58 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.1104.5; Sat, 31 Oct 2015 05:00:31 -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.1104.000; Sat, 31 Oct 2015 05:00:31 -0500 From: "Pascal Thubert (pthubert)" To: Ralph Droms Thread-Topic: INT-DIR review of draft-ietf-6tisch-minimal-12 Thread-Index: AQHRE5QKIsyJf5E/CUa5+QTBXYBKXp6FXOZw Date: Sat, 31 Oct 2015 10:00:27 +0000 Deferred-Delivery: Sat, 31 Oct 2015 09:59:56 +0000 Message-ID: References: <20A7A202-73D1-4071-9AC4-5E06ED10FF5D@gmail.com> In-Reply-To: <20A7A202-73D1-4071-9AC4-5E06ED10FF5D@gmail.com> 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.61.94.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-6tisch-minimal.all@ietf.org" , "" Subject: Re: [Int-dir] INT-DIR review of draft-ietf-6tisch-minimal-12 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 10:01:03 -0000 All good points, Ralph. I agree with the need to improve the abstract.=20 The main structure of a 6TiSCH network with RPl and all is in the architect= ure draft but that doc is now delayed. 6LoWPAN ND does not really have options so there was no need to spend text = on it. We could mention it though, since the architecture cannot be referen= ced. Cheers, Pascal > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: samedi 31 octobre 2015 13:25 > To: Pascal Thubert (pthubert) > Cc: ; draft-ietf-6tisch- > minimal.all@ietf.org > Subject: Re: INT-DIR review of draft-ietf-6tisch-minimal-12 >=20 >=20 > > On Oct 31, 2015, at 12:45 PM 10/31/15, Pascal Thubert (pthubert) > wrote: > > > > Hello Ralph > > > > Regarding specifically your item 2, about RPL. > > > > This may be related to your item 1 (clarity of the goal) but your comm= ent > indicates that you missed the point of this draft. > > > > The point is to document a collection of protocols and settings that wi= ll > enable to build a 6TiSCH mesh network and lead to interoperable > implementations. >=20 > OK, but the first sentence of the abstract is: >=20 > This document describes the minimal set of rules to operate an IEEE > 802.15.4 Timeslotted Channel Hopping (TSCH) network. >=20 > The *only* occurrence of the string "6tisch" (case insensitive) in the te= xt of > this document (not in citations, etc.) is in the Acknowledgments section: >=20 > Also our acknowledge to the 6TiSCH > Chairs Pascal Thubert and Thomas Watteyne for their guideance and > advice. >=20 > How in the world would anyone know this document is intended to cover > the entire stack as required by a "6TiSCH mesh network". >=20 > > 6TiSCH defined that this minimal collection would include a TSCH MAC, > IPv6, 6LoWPAN and RPL. This makes full sense to me and in any fashion is > the group decision. >=20 > I didn't say it wasn't a group decision ... I disagree with the group dec= ision, > as I understood the purpose of this document from the Abstract. >=20 > If this document is really supposed to describe the minimal requirements > for the whole stack in a "6TiSCH mesh network", doesn't it need text > describing address assignment, which flavor and how to use ND, etc., etc. >=20 > - Ralph >=20 > > > > Cheers, > > > > Pascal > > > >> -----Original Message----- > >> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > >> Sent: samedi 31 octobre 2015 08:49 > >> To: ; draft-ietf-6tisch- > >> minimal.all@ietf.org > >> Subject: Re: INT-DIR review of draft-ietf-6tisch-minimal-12 > >> > >> I just noticed I didn't complete the text for comment 10. Here is > >> the revised review. > >> > >> I am an assigned INT directorate reviewer for draft-ietf-6tisch-minima= l- > 12. > >> 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. > >> > >> Review submitted by Ralph Droms > >> > >> Summary: In my opinion, the WG needs to reconsider some of the > >> fundamental aspects of this proposed specification, and the document > >> needs significant restructuring and editing. I will be happy to work > >> with the WG to revise the document and review future revisions. > >> > >> There may be overlaps between my comments and those in other > reviews > >> because I avoided reading those reviews before writing up my review. > >> > >> Here are my comments on the document. The first four comments > apply > >> to the document as a whole, while the remainder address more specific > >> issues, roughly in the order of appearance in the document. > >> > >> 1. Goals and requirements are unclear > >> > >> The requirements for this document are unclear to me. Exactly what > >> services would a "minimal mode of operation" provide? The Abstract > >> and most of the document talks about the operation of an IEEE > >> 802.15.4 TSCH network, yet the title of the document is "Minimal > 6TiSCH Configuration". > >> Does a network that follows these rules provide an L2 IEEE 802.15.4 > >> service, an IPv6 6TiSCH service, ??? > >> > >> Related to this question, does this document describe "a minimal set > >> of rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal > >> mode of operation" (both text snippets from the Abstract). > >> > >> 2. Requirement for RPL is ill-advised > >> > >> This document seems to be focused on IEEE 802.15.4 TSCH operational > >> parameters. Yet, it calls for the use of RPL, which seems to me to > >> be a highly undesirable entangling of protocols at different layers > >> of the protocol stack. IEEE 802.15.4 TSCH is expected to be used in > >> networks that don't use RPL. > >> > >> My understanding of the document is that RPL is assumed to be in use > >> because it is required in a 6TiSCH network. RPL is then used to > >> generate the Join Priority through the DAGRank function as specified > >> in section 7.2. The use of RPL implies to me the configuration and > >> operation of a full IPv6 stack, which hardly seems like a minimal > >> mode of operation for IEEE > >> 802.15.4 TSCH. > >> > >> I have a question about this text from section 7.2: > >> > >> When a node joins the network, > >> it MUST NOT send EBs before having acquired a RPL rank. This avoids > >> routing loops and matches RPL topology with underlying mesh > topology. > >> > >> What is meant by "avoiding routing loops"? My understanding is that > >> IEEE > >> 802.15.4 TSCH simply provides for frame delivery between neighbors > >> and does not provide frame forwarding. How would routing loops arise > >> from running IEEE 802.15.4 TSCH? > >> > >> Has the WG considered reorganizing the 6TiSCH protocol suite and > >> documents to separate the minimal operation of IEEE 802.15.4 TSCH > >> from IPv6/RPL/ND/etc? For example, has the WG considered allowing a > >> simpler, initial Join Priority scheme that would provide minimal IEEE > >> 802.15.4 TSCH operation until the full IPv6 suite is running, at > >> which time RPL will provide optimal routing. > >> > >> 3. Restatement of specifications in IEEE 802.15.4 documents > >> > >> I haven't read the most recent IEEE 802.15.4 docs and it has been a > >> while since I took a close look at earlier revs. With that > >> disclaimer in mind, how much of the text in sections 3 through 9 is a > >> restatement of the IEEE > >> 802.15.4 specification and how much is the specification of > >> operational parameters for minimal operation of a IEEE 802.15.4 TSCH > network? > >> Restatement of specifications can be confusing and lead to a lack of > >> interoperability. As a small example, here is section 6: > >> > >> 6. Acknowledgment > >> > >> Link-layer acknowledgment frames are built according to > [IEEE802154]. > >> Unicast frames sent to a unicast MAC destination address MUST > request > >> an acknowledgment. The sender node MUST set the ACK requested > >> bit in > >> the MAC header. The acknowledgment frame is of type ACK (frame > type > >> value 0b010). Each acknowledgment contains the following IE: > >> > >> ACK/NACK Time Correction IE: The ACK/NACK time correction IE > >> carries the measured de-synchronization between the sender and > the > >> receiver. Refer to Section 11.3 for an example of the Header IE > >> content. The possible values for the Time Synchronization > >> Information and ACK status are described in [IEEE802154]. > >> > >> Out of that section, it seems to me that the first sentence is > >> harmless, the second sentence is a specification for this document, > >> the third and fourth sentences are a restatement of [IEEE802154] and > >> the fifth sentence is an inferred specification for this document. > >> The description of the IE is a restatement of [IEEE802154]. > >> > >> Section 6 could be rewritten as: > >> > >> 6. Acknowledgement frames > >> > >> Unicast frames sent to a unicast MAC destination address MUST > request > >> an acknowledgment. Each acknowledgment MUST contain an > ACK/NACK > >> Time Correction IE. > >> > >> 4. Default behavior versus learned behavior > >> > >> Which of the configuration and operational specifications in this > >> document must be pre-configured before a node joins the network, and > >> which are learned through, e.g., EBs. Are operational control and > >> management questions out of scope for this document, such as: > >> > >> - when does a node switch from the "minimal 6TiSCH configuration" to > >> some other configuration? > >> - does a node use the configuration parameters it has received > >> through EBs to generate its own EBs or does it use the "minimal > >> 6TiSCH configuration" parameters? > >> > >> 5. In this text from the Introduction, does "synchronizes with the > network" > >> mean time synchronization or something else: > >> > >> [...] when a node synchronizes to the network. > >> > >> 6. I don't think the last sentence of the Introduction is relevant to > >> an Introduction. > >> > >> 7. The document could use a section on the terminology used in the > >> document, to provide definitive sources for definitions of the > >> various terms and acronyms used in the document. Most likely, the > >> terminology section would simply point to relevant sections of > >> [IEEE802154] and [I-D.ietf-6tisch- terminology]. > >> > >> 8. Section 11 should be an Appendix, rather than part of the body of > >> the document, so as to avoid making those examples normative > standards text. > >> > >> 9. I think the contents of section 7.1 are entirely dependent on the > >> specifics of an implementation and the section should be omitted. > >> > >> 10. I think the information in section 8 would be more generally > >> useful if not stated in terms of a queue-based implementation: > >> > >> A node must not transmit frames containing higher-layer packets > >> until the node has successfully joined a network. > >> > >> Frames generated by the IEEE 802.15.4 layer are transmitted before > >> frames containing higher-layer packets. > >> > >> Frame types BEACON and COMMAND are transmitted before frame > types > >> DATA and ACK. > >> > >> A node has to be prepared to send a BEACON or COMMAND frame at > any > >> time. > >> > >> I've tried to infer the desired behavior from the description of queue > usage. > >> If I understand the original text correctly, there is no difference > >> between the second and third requirements. > >> > >> 11. According to [I-D.ietf-6tisch-terminology], the correct term is > >> "timeslot", so s/time slot/timeslot/ throughout the document. > >> > >> 12. In the table at the top of page 4 (BTW, please number and add a > >> title to all tables), are the listed properties the only properties > >> that have numeric or short text string values? If not, all of those > >> properties should be gathered together into a single table. As an > >> editorial aside, this table is pretty much what I expected to be the b= ulk > of this document. > >> > >> 13. Even if the number of timeslots in a slotframe is variable for > >> this minimal configuration, should there be a default? > >> > >> 14. In the table at the top of page 5, what do the empty boxes > represent? > >> > >> 15. The last sentence of section 3.2 seems to be a low-level > >> implementation detail that can be omitted. > >> > >> 16. Without having read the IEEE 802.15.4 docs recently to confirm, > >> I'll suggest that almost all of section 3.4 is a restatement of the > >> IEEE 802.15.4 spec. The last sentence is important, and isn't > >> entirely clear. It would be clearer to write: > >> > >> For the minimal configuration specified in this document, the use > >> of CCA is OPTIONAL. > >> > >> 17. End of section 3 - not clear when to use macTimeslotTemplate. > >> > >> 18. The third paragraph of section 4 is completely unclear to me: > >> > >> A Node aiming to join the network by receving a properly formed > >> BEACON shall enter in a scan phase and shall store the value of > >> macPANId and then set it to 0xffff for the duration of the scan in > >> order to meet the filtering rules in [IEEE802154]. > >> > >> What are "macPANId" and "scan phase"? I don't see those terms used > >> anywhere else in this document; do the terms come from the IEEE > >> 802.15.4 specs? Why would an implementation store the value of > >> macPANId and then set it to 0xffff? > >> > >> 19. Does "synchronization" in section 5 mean "time synchronization"? > >> > >> 20. In section 5, is "EB_PERIOD" the same value as defined in the > >> table in section 10.2.4 that defines "RPL-related variables"? If so, > >> I don't understand why "EB_PERIOD" is in that table, as it only > >> appears once in the rest of the document in section 5. > >> > >> 21. I see that section 10 includes the statement: > >> > >> Nodes in a multihop network MUST use the RPL routing protocol > >> [RFC6550]. > >> > >> This statement is certainly false if one takes a broad definition of > >> the word "multihop". Even if edited to "multilink subnet" or "mesh", > >> I can't find any support in RFC 6550 for the statement "MUST use RPL > >> routing protocol". I think it would be much clearer and more correct > >> to quote verbatim the text describing this requirement from RFC 6550 > >> rather than paraphrasing it here. > >> > >> Similarly, this sentence in section 10.1 needs, at least, to be > >> edited, and I think it should be replaced with quoted text from RFC 65= 52. > >> > >> Nodes in the multihop network MUST implement the RPL Objective > >> Function Zero [RFC6552]. > >> > >> While I haven't provided a detailed review of the remainder of > >> section > >> 10 because I don't think it's necessary for the goals of this > >> document, it appears to me that much of section 10 is a restatement > >> of the RPL specification from RFC 6550 and should, therefore, be > >> omitted (if RPL is retained as a part of this recommendation). > > From nobody Sat Oct 31 15:45:12 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5ED1B2BEF; Sun, 25 Oct 2015 01:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 lSYLhB4m73u5; Sun, 25 Oct 2015 01:26:46 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9BC1B2BED; Sun, 25 Oct 2015 01:26:46 -0700 (PDT) Received: by qgad10 with SMTP id d10so98173809qga.3; Sun, 25 Oct 2015 01:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e009fI5RsZ6DHUNxVgEJl6gR5GhhLtFnZz4U1EiJXAA=; b=rTwe9bcPWngB8crmaIguLz34mI02rUHzxcOUUnPS3l6zAEPC71MLDNxSdQwrbcuANh AptzZ2Kl2HcSkR53wbJ7PepMGW/dk1HqPj0HkTQraqizdfJKS66sm9a213/fAvCzygOx p3NPOrT2KivuWW0VsRfFwcLcgWqDwnj1cCAutRmwNduBItmEv6/ilxAF/269w4DhF8Zc Ay1PQrLCq5KEsyOEApYJXaTkGIN7ODc4IwLc+KQPvopDPO9/7ZhjxN69VxlCX9OeFvUx hFpsXkGgpGwebsAzO8M8fRwzWPZkCQPbU/Nef5TQEEHcsYGmSioMHtXu9CfarUVXh+s4 vQNg== MIME-Version: 1.0 X-Received: by 10.140.148.74 with SMTP id 71mr37746961qhu.26.1445761605806; Sun, 25 Oct 2015 01:26:45 -0700 (PDT) Received: by 10.140.89.203 with HTTP; Sun, 25 Oct 2015 01:26:45 -0700 (PDT) In-Reply-To: <32E92224-BB99-4B2C-8138-8DDB4A6DC054@cisco.com> References: <32E92224-BB99-4B2C-8138-8DDB4A6DC054@cisco.com> Date: Sun, 25 Oct 2015 10:26:45 +0200 Message-ID: From: Dong Jiang To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a11355ea0f1aebd0522e99a58 Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 15:45:11 -0700 Cc: "draft-ietf-softwire-mesh-mib.all@ietf.org" , "int-ads@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2015 08:26:49 -0000 --001a11355ea0f1aebd0522e99a58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Carlos, Thank you for the comments! We'll revise the draft accordingly. Best regards, Jiang 2015-10-22 22:00 GMT+03:00 Carlos Pignataro (cpignata) = : > Hi, > > I am an assigned INT directorate reviewer for > draft-ietf-softwire-mesh-mib-11. These comments were written primarily fo= r > the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat commen= ts > from any other IETF contributors and resolve them along with any other La= st > Call comments that have been received. For more details on the INT > Directorate, see http://www.ietf.org/iesg/directorate/intarea.html. > > This document defines MIB objects to manage softwire mesh solutions, and > targets the Standards Track. > > I have a number of comments and concerns with this document, which amount > to requesting the ADs to take a closer look: > > 3. Terminology > > This document uses terminology from the softwire problem statement > RFC 4925 [RFC4925] and the softwire mesh framework RFC 5565 > [RFC5565]. > > CMP: I think terminology from RFC 5512 is also heavily used. > > 5.1. The swmSupportedTunnelTable Subtree > > According > to section 4 of RFC 5512 [RFC5512], current softwire mesh tunnel > types include IP-IP, GRE and L2TPv3. > > CMP: This is true, but at the same time there are now many other =E2=80= =9Ccurrent > tunnel types=E2=80=9D (which are actually BGP Tunnel Encapsulation Attrib= ute Tunnel > Types). See > http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunne= l-types Specifically > the ones introduced by RFC5566 ought to be included. > > CMP: This comment also applies to swmSupportedTunnelType > > XX. Missing sub-TLVs > > CMP: If the Tunnel Type is one which requires encapsulation information > (e.g., L2TPv3 Session ID, Cookie, GRE Key, etc.), how is that information > managed? I cannot seem to find it in the MIB Module. See Section 4.1 of R= FC > 5512. > > CMP: Similarly, what about Protocol Type and Color (S4.2 and 4.3 of RFC > 5512), and IPsec Tunnel Authenticator (RFC 5566)? > > CMP: Similarly, what about the Load-Balancing Block values from RFC 5640? > Without this, an ECMP-aware L2TPv3 tunnel will be misunderstood. > > 8. Security Considerations > > The swmMIB module can be used for configuration of certain objects, > > CMP: How is this so, without read-write or read-create? > > 11. References > > 11.1. Normative References > > CMP: Curiously, I do not see RFC 5566 or RFC 5640 referenced. > > Hope these help! > > Thanks, > > =E2=80=94 Carlos. > > --001a11355ea0f1aebd0522e99a58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Carlos,

Thank you for the comments= ! We'll revise the draft accordingly.

Best reg= ards,
Jiang=C2=A0

2015-10-22 22:00 GMT+03:00 Carlos Pignataro (cpignata= ) <cpignata@cisco.com>:
<= div style=3D"word-wrap:break-word">
Hi,

I am an= assigned INT directorate reviewer for draft-ietf-softwire-mesh-mib-11.=C2= =A0These comments were written primarily for the benefit of the Internet=C2= =A0Area Directors. Document editors and shepherd(s) should treat these=C2= =A0comments just like they would treat comments from any other IETF=C2=A0co= ntributors and resolve them along with any other Last Call comments=C2=A0th= at have been received. For more details on the INT Directorate,=C2=A0see=C2= =A0http://www.ietf.org/iesg/directorate/intarea.html.
This document defines MIB objects to manage softwi= re mesh solutions, and targets the Standards Track.

I have a number of comments and concerns with this document, which amount= to requesting the ADs to take a closer look:

3.= =C2=A0 Terminology

=C2=A0 =C2=A0This document uses terminology = from the softwire problem statement
=C2=A0 =C2=A0RFC 4925=C2=A0[R= FC4925] and the softwire mesh framework=C2=A0RFC 5565
=C2= =A0=C2=A0 [RFC5565].

CMP: I think terminology from= RFC 5512 is also heavily used.

5.1.=C2=A0 The swm= SupportedTunnelTable Subtree

=C2=A0 =C2=A0According<= /div>
=C2=A0 =C2=A0to section 4 of RFC 5512=C2=A0[RFC5512], current sof= twire mesh tunnel
=C2=A0 =C2=A0types include IP-IP, GRE and L2TPv= 3.

CMP: This is true, but at the same time t= here are now many other =E2=80=9Ccurrent tunnel types=E2=80=9D (which are a= ctually BGP Tunnel Encapsulation Attribute Tunnel Types). See=C2=A0http://www.iana.org/assignments/bgp-parameters= /bgp-parameters.xhtml#tunnel-types=C2=A0Specifically the ones introduce= d by RFC5566 ought to be included.

CMP: This comme= nt also applies to swmSupportedTunnelType

XX. Miss= ing sub-TLVs

CMP: If the Tunnel Type is one which = requires encapsulation information (e.g., L2TPv3 Session ID, Cookie, GRE Ke= y, etc.), how is that information managed? I cannot seem to find it in the = MIB Module. See Section 4.1 of RFC 5512.

CMP: Simi= larly, what about Protocol Type and Color (S4.2 and 4.3 of RFC 5512), and= =C2=A0IPsec Tunnel Authenticator (RFC 5566)?

CMP: = Similarly, what about the Load-Balancing Block values from RFC 5640? Withou= t this, an ECMP-aware L2TPv3 tunnel will be misunderstood.

8.=C2=A0 Security Considerations

=C2=A0 =C2=A0The swmM= IB module can be used for configuration of certain objects,

CMP: How is this so, without read-write or read-create?

11.=C2=A0 References

11.1.=C2=A0 Normative Ref= erences

CMP: Curiously, I do not see RFC 5566 or R= FC 5640 referenced.

Hope these help!
Thanks,

=E2=80=94 Carlos.

--001a11355ea0f1aebd0522e99a58-- From nobody Sat Oct 31 15:45:13 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8681AC42E; Mon, 26 Oct 2015 00:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 HDbk8rh99iZX; Mon, 26 Oct 2015 00:20:28 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8AF71AC42B; Mon, 26 Oct 2015 00:20:27 -0700 (PDT) Received: by qgeo38 with SMTP id o38so113184517qge.0; Mon, 26 Oct 2015 00:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R6vk+gIfw0gkDyKWdmZJpcEBts1t2/JmllXIrbjYLJo=; b=Xohqk4xSxTnhrkuJs/aYh1fVeccrlD99+SPPj705HMP1WPOZ89YiJIUVCS0c2MAfpe z/CE1jklFMrqt/BCTjTRz+Q39Y4SHu+UI54/5ZnPA6HxTQl+AW3NuuM++G6JA4B9YToS jPQ6nqlUCQnweQ++Nl0RPE3sEzRrGIwBdVYgdEhdX4ggLHA2WGyiaXsEE0RO8tDW8/Iq 2q0GtHg5bua9Sf0vp2q6ku27Gv3upcY4FRhPUb5K6fje9mNf6uPzFVBRGbjMAuROeMhM knrl1+MXXbR8JPWvUjqkRpkPs7Xk97CATg4r4hAw4//Ge+8pPlvLigSgzz31jXhrY0XG 5/gQ== MIME-Version: 1.0 X-Received: by 10.140.148.74 with SMTP id 71mr43180070qhu.26.1445844026950; Mon, 26 Oct 2015 00:20:26 -0700 (PDT) Received: by 10.140.89.203 with HTTP; Mon, 26 Oct 2015 00:20:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Oct 2015 09:20:26 +0200 Message-ID: From: Dong Jiang To: Hui Deng Content-Type: multipart/alternative; boundary=001a11355ea0a0898a0522fccb97 Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 15:45:11 -0700 Cc: draft-ietf-softwire-mesh-mib.all@ietf.org, int-ads@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 07:20:34 -0000 --001a11355ea0a0898a0522fccb97 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Deng Hui, Thank you for the comments! We'll revise the draft accordingly. Best regards, Jiang 2015-10-25 9:55 GMT+02:00 Hui Deng : > Hi > > I am an assigned INT directorate reviewer for > draft-ietf-softwire-mesh-mib-11. These comments were written primarily fo= r > 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 th= em > 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/intarea.html. > > This document defines MIB objects to manage softwire mesh solutions, and > targets the Standards Track. > > Please find below review comments: > > 1) Page 5 in section 6.2, =E2=80=9CThe tunnelIfRemoteInetAddress MUST be = set to > 0.0.0.0 for IPv4 or :: for IPv6 because it is a point to multi-point > tunnel.=E2=80=9D > It needs quotation mark for 0.0.0.0 and :: > > 2) In the MIB definitions, it needs REFERENCE for the IMPORT objects. eg: > swmEncapsEIPDst OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The E-IP destination prefix, which is > used for I-IP encapsulation destination looking up." > ::=3D { swmEncapsEntry 2 } > > It should add a REFERENCE =E2=80=9CE-IP and I-IP in RFC 5565 =E2=80=9D. T= he same comment > for the definition of swmEncapsIIPDst. > > 3) In page 8, > swmEncapsEIPDstType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object specifies the address type used for > swmEncapsEIPDst. It is different from the tunnelIfAddressType > in the tunnelIfTable." > ::=3D { swmEncapsEntry 1 } > > It should list ipv4(1) and ipv6(2) in the DESCRIPTION for different > scenario. Also it should add a REFERENCE to RFC 4001. > > 4) In page 8, SwmEncapsEntry: I think swmEncapsEIPDstType and > swmEncapsIIPDstType should just be swmEncapsIPDstType and apply to both. = If > all address objects in > > the row are of the same type, you only need one type object. > > 5) In page 7, =E2=80=9CRepresents the tunnel type that the AFBR supports= =E2=80=9D in > definition of swmSupportedTunnelType. It need a clarification that It > represents the tunnel > > type used for softwire mesh scenario. > > 6) As it states in the section 6.1, the ifInucastPkts counts the number > of IPv6 packets which are sent to the virtual interface for decapsulation > into IPv4. I > > think it need some statistics objects to define for the softwire mesh suc= h > as the number of the connection tunnel when running point to multi-point > tunnel. > > 7) Why not define a parameter for swmEncapsIIPDstPrefixLength? > > 8) In the swmEncapsGroup, there are only information about > swmEncapsIIPDst and swmEncapsIIPDstType, why there are not swmEncapsEIPDs= t > and swmEncapsIIPType and so on? > > Best regards, > > DENG Hui > --001a11355ea0a0898a0522fccb97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Deng Hui,

Thank you for the comments! We'll revise the draft accordingly.

B= est regards,
Jiang=C2=A0

2015-10-25 9:55 GMT+0= 2:00 Hui Deng <denghui02@gmail.com>:
=
Hi

I am an assigned INT directorat= e reviewer for draft-ietf-softwire-mesh-mib-11. These comments were written= primarily for the benefit of the Internet Area Directors.=C2=A0
=
Document editors and shepherd(s) should treat these comments= just like they would treat comments from any other IETF contributors and r= esolve them along with any other=C2=A0

Last Call c= omments that have been received. For more details on the INT Directorate, s= ee http://www.ietf.org/iesg/directorate/intarea.html.
This document defines MIB objects to manage softwire mesh solu= tions, and targets the Standards Track.

Please fin= d below review comments:

1) Page 5 in section 6.2, =E2=80=9CThe tunnelIfRemoteIne= tAddress MUST be set to 0.0.0.0 for IPv4 or :: for IPv6 because it is a poi= nt to multi-point tunnel.=E2=80=9D=C2=A0
It needs quotation mark = for 0.0.0.0 and ::

2) In the MIB definitions, it needs REFERENCE for the IMPORT o= bjects. eg:
swmEncapsEIPDst OBJECT-TYPE
SYNTAX InetAddr= ess
MAX-ACCESS not-accessible
STATUS current
= DESCRIPTION
"The E-IP destination prefix, which is
used for I-IP encapsulation destination looking up."
::=3D = { swmEncapsEntry 2 }

It should add a REFERENCE =E2= =80=9CE-IP and I-IP in RFC 5565 =E2=80=9D. The same comment for the definit= ion of swmEncapsIIPDst.

3) In page 8,=C2=A0
swmEncapsEIPDstType OBJECT-= TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object s= pecifies the address type used for
swmEncapsEIPDst. It is differe= nt from the tunnelIfAddressType
in the tunnelIfTable."
=
::=3D { swmEncapsEntry 1 }

It should list ipv= 4(1) and ipv6(2) in the DESCRIPTION for different scenario. Also it should = add a REFERENCE to RFC 4001.

4) In page 8, SwmEncapsEntry: I think swmEncapsEIPDs= tType and swmEncapsIIPDstType should just be swmEncapsIPDstType and apply t= o both. If all address objects in=C2=A0

the row ar= e of the same type, you only need one type object.

5) In page 7, =E2=80=9CReprese= nts the tunnel type that the AFBR supports=E2=80=9D in definition of swmSup= portedTunnelType. It need a clarification that It represents the tunnel=C2= =A0

type used for softwire mesh scenario.

6) As it state= s in the section 6.1, the ifInucastPkts counts the number of IPv6 packets w= hich are sent to the virtual interface for decapsulation into IPv4. I=C2=A0=

think it need some statistics objects to define f= or the softwire mesh such as the number of the connection tunnel when runni= ng point to multi-point tunnel.

7) Why not define a parameter for swmEncapsIIPDst= PrefixLength?=C2=A0

8) In the swmEncapsGroup, there are only information about sw= mEncapsIIPDst and swmEncapsIIPDstType, why there are not swmEncapsEIPDst an= d swmEncapsIIPType and so on?=C2=A0

Best reg= ards,

DENG Hui

--001a11355ea0a0898a0522fccb97-- From nobody Sat Oct 31 20:21:44 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500FE1B5668; Sat, 31 Oct 2015 20:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 a9zIHmFpwhpG; Sat, 31 Oct 2015 20:21:40 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AAD1B5665; Sat, 31 Oct 2015 20:21:40 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 15140880C2; Sat, 31 Oct 2015 20:21:40 -0700 (PDT) Received: from clemson.local (unknown [133.93.24.158]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E1918328081A; Sat, 31 Oct 2015 20:21:38 -0700 (PDT) To: "Pascal Thubert (pthubert)" , Ralph Droms References: <20A7A202-73D1-4071-9AC4-5E06ED10FF5D@gmail.com> From: Brian Haberman Message-ID: <5635853B.1070404@innovationslab.net> Date: Sat, 31 Oct 2015 23:21:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7OumEuPsRHxuqQf09recvgOGTTtEqXHRH" Archived-At: Cc: "draft-ietf-6tisch-minimal.all@ietf.org" , "" Subject: Re: [Int-dir] INT-DIR review of draft-ietf-6tisch-minimal-12 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 03:21:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7OumEuPsRHxuqQf09recvgOGTTtEqXHRH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Pascal, On 10/31/15 6:00 AM, Pascal Thubert (pthubert) wrote: > All good points, Ralph. >=20 > I agree with the need to improve the abstract. >=20 > The main structure of a 6TiSCH network with RPl and all is in the > architecture draft but that doc is now delayed. Saying the architecture draft is delayed appears to make it sound like it is stuck. It is only delayed because the WG is not actively trying to address all the comments that were raised during review. Brian >=20 > 6LoWPAN ND does not really have options so there was no need to spend > text on it. We could mention it though, since the architecture cannot > be referenced. >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- From: Ralph Droms >> [mailto:rdroms.ietf@gmail.com] Sent: samedi 31 octobre 2015 13:25=20 >> To: Pascal Thubert (pthubert) Cc: >> ; draft-ietf-6tisch-=20 >> minimal.all@ietf.org Subject: Re: INT-DIR review of >> draft-ietf-6tisch-minimal-12 >>=20 >>=20 >>> On Oct 31, 2015, at 12:45 PM 10/31/15, Pascal Thubert (pthubert) >> wrote: >>>=20 >>> Hello Ralph >>>=20 >>> Regarding specifically your item 2, about RPL. >>>=20 >>> This may be related to your item 1 (clarity of the goal) but >>> your comment >> indicates that you missed the point of this draft. >>>=20 >>> The point is to document a collection of protocols and settings >>> that will >> enable to build a 6TiSCH mesh network and lead to interoperable=20 >> implementations. >>=20 >> OK, but the first sentence of the abstract is: >>=20 >> This document describes the minimal set of rules to operate an >> IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network. >>=20 >> The *only* occurrence of the string "6tisch" (case insensitive) in >> the text of this document (not in citations, etc.) is in the >> Acknowledgments section: >>=20 >> Also our acknowledge to the 6TiSCH Chairs Pascal Thubert and Thomas >> Watteyne for their guideance and advice. >>=20 >> How in the world would anyone know this document is intended to >> cover the entire stack as required by a "6TiSCH mesh network". >>=20 >>> 6TiSCH defined that this minimal collection would include a TSCH >>> MAC, >> IPv6, 6LoWPAN and RPL. This makes full sense to me and in any >> fashion is the group decision. >>=20 >> I didn't say it wasn't a group decision ... I disagree with the >> group decision, as I understood the purpose of this document from >> the Abstract. >>=20 >> If this document is really supposed to describe the minimal >> requirements for the whole stack in a "6TiSCH mesh network", >> doesn't it need text describing address assignment, which flavor >> and how to use ND, etc., etc. >>=20 >> - Ralph >>=20 >>>=20 >>> Cheers, >>>=20 >>> Pascal >>>=20 >>>> -----Original Message----- From: Ralph Droms >>>> [mailto:rdroms.ietf@gmail.com] Sent: samedi 31 octobre 2015 >>>> 08:49 To: ; >>>> draft-ietf-6tisch- minimal.all@ietf.org Subject: Re: INT-DIR >>>> review of draft-ietf-6tisch-minimal-12 >>>>=20 >>>> I just noticed I didn't complete the text for comment 10. Here >>>> is the revised review. >>>>=20 >>>> I am an assigned INT directorate reviewer for >>>> draft-ietf-6tisch-minimal- >> 12. >>>> 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=20 >>>> details on the INT Directorate, see >> http://www.ietf.org/iesg/directorate.html. >>>>=20 >>>> Review submitted by Ralph Droms >>>>=20 >>>> Summary: In my opinion, the WG needs to reconsider some of the=20 >>>> fundamental aspects of this proposed specification, and the >>>> document needs significant restructuring and editing. I will >>>> be happy to work with the WG to revise the document and review >>>> future revisions. >>>>=20 >>>> There may be overlaps between my comments and those in other >> reviews >>>> because I avoided reading those reviews before writing up my >>>> review. >>>>=20 >>>> Here are my comments on the document. The first four comments >> apply >>>> to the document as a whole, while the remainder address more >>>> specific issues, roughly in the order of appearance in the >>>> document. >>>>=20 >>>> 1. Goals and requirements are unclear >>>>=20 >>>> The requirements for this document are unclear to me. Exactly >>>> what services would a "minimal mode of operation" provide? The >>>> Abstract and most of the document talks about the operation of >>>> an IEEE 802.15.4 TSCH network, yet the title of the document is >>>> "Minimal >> 6TiSCH Configuration". >>>> Does a network that follows these rules provide an L2 IEEE >>>> 802.15.4 service, an IPv6 6TiSCH service, ??? >>>>=20 >>>> Related to this question, does this document describe "a >>>> minimal set of rules to operate an IEEE802.15.4 ...] TSCH >>>> network" or a "minimal mode of operation" (both text snippets >>>> from the Abstract). >>>>=20 >>>> 2. Requirement for RPL is ill-advised >>>>=20 >>>> This document seems to be focused on IEEE 802.15.4 TSCH >>>> operational parameters. Yet, it calls for the use of RPL, >>>> which seems to me to be a highly undesirable entangling of >>>> protocols at different layers of the protocol stack. IEEE >>>> 802.15.4 TSCH is expected to be used in networks that don't use >>>> RPL. >>>>=20 >>>> My understanding of the document is that RPL is assumed to be >>>> in use because it is required in a 6TiSCH network. RPL is then >>>> used to generate the Join Priority through the DAGRank function >>>> as specified in section 7.2. The use of RPL implies to me the >>>> configuration and operation of a full IPv6 stack, which hardly >>>> seems like a minimal mode of operation for IEEE 802.15.4 TSCH. >>>>=20 >>>> I have a question about this text from section 7.2: >>>>=20 >>>> When a node joins the network, it MUST NOT send EBs before >>>> having acquired a RPL rank. This avoids routing loops and >>>> matches RPL topology with underlying mesh >> topology. >>>>=20 >>>> What is meant by "avoiding routing loops"? My understanding is >>>> that IEEE 802.15.4 TSCH simply provides for frame delivery >>>> between neighbors and does not provide frame forwarding. How >>>> would routing loops arise from running IEEE 802.15.4 TSCH? >>>>=20 >>>> Has the WG considered reorganizing the 6TiSCH protocol suite >>>> and documents to separate the minimal operation of IEEE >>>> 802.15.4 TSCH from IPv6/RPL/ND/etc? For example, has the WG >>>> considered allowing a simpler, initial Join Priority scheme >>>> that would provide minimal IEEE 802.15.4 TSCH operation until >>>> the full IPv6 suite is running, at which time RPL will provide >>>> optimal routing. >>>>=20 >>>> 3. Restatement of specifications in IEEE 802.15.4 documents >>>>=20 >>>> I haven't read the most recent IEEE 802.15.4 docs and it has >>>> been a while since I took a close look at earlier revs. With >>>> that disclaimer in mind, how much of the text in sections 3 >>>> through 9 is a restatement of the IEEE 802.15.4 specification >>>> and how much is the specification of operational parameters for >>>> minimal operation of a IEEE 802.15.4 TSCH >> network? >>>> Restatement of specifications can be confusing and lead to a >>>> lack of interoperability. As a small example, here is section >>>> 6: >>>>=20 >>>> 6. Acknowledgment >>>>=20 >>>> Link-layer acknowledgment frames are built according to >> [IEEE802154]. >>>> Unicast frames sent to a unicast MAC destination address MUST >> request >>>> an acknowledgment. The sender node MUST set the ACK requested=20 >>>> bit in the MAC header. The acknowledgment frame is of type ACK >>>> (frame >> type >>>> value 0b010). Each acknowledgment contains the following IE: >>>>=20 >>>> ACK/NACK Time Correction IE: The ACK/NACK time correction IE=20 >>>> carries the measured de-synchronization between the sender and >> the >>>> receiver. Refer to Section 11.3 for an example of the Header >>>> IE content. The possible values for the Time Synchronization=20 >>>> Information and ACK status are described in [IEEE802154]. >>>>=20 >>>> Out of that section, it seems to me that the first sentence is=20 >>>> harmless, the second sentence is a specification for this >>>> document, the third and fourth sentences are a restatement of >>>> [IEEE802154] and the fifth sentence is an inferred >>>> specification for this document. The description of the IE is a >>>> restatement of [IEEE802154]. >>>>=20 >>>> Section 6 could be rewritten as: >>>>=20 >>>> 6. Acknowledgement frames >>>>=20 >>>> Unicast frames sent to a unicast MAC destination address MUST >> request >>>> an acknowledgment. Each acknowledgment MUST contain an >> ACK/NACK >>>> Time Correction IE. >>>>=20 >>>> 4. Default behavior versus learned behavior >>>>=20 >>>> Which of the configuration and operational specifications in >>>> this document must be pre-configured before a node joins the >>>> network, and which are learned through, e.g., EBs. Are >>>> operational control and management questions out of scope for >>>> this document, such as: >>>>=20 >>>> - when does a node switch from the "minimal 6TiSCH >>>> configuration" to some other configuration? - does a node use >>>> the configuration parameters it has received through EBs to >>>> generate its own EBs or does it use the "minimal 6TiSCH >>>> configuration" parameters? >>>>=20 >>>> 5. In this text from the Introduction, does "synchronizes with >>>> the >> network" >>>> mean time synchronization or something else: >>>>=20 >>>> [...] when a node synchronizes to the network. >>>>=20 >>>> 6. I don't think the last sentence of the Introduction is >>>> relevant to an Introduction. >>>>=20 >>>> 7. The document could use a section on the terminology used in >>>> the document, to provide definitive sources for definitions of >>>> the various terms and acronyms used in the document. Most >>>> likely, the terminology section would simply point to relevant >>>> sections of [IEEE802154] and [I-D.ietf-6tisch- terminology]. >>>>=20 >>>> 8. Section 11 should be an Appendix, rather than part of the >>>> body of the document, so as to avoid making those examples >>>> normative >> standards text. >>>>=20 >>>> 9. I think the contents of section 7.1 are entirely dependent >>>> on the specifics of an implementation and the section should be >>>> omitted. >>>>=20 >>>> 10. I think the information in section 8 would be more >>>> generally useful if not stated in terms of a queue-based >>>> implementation: >>>>=20 >>>> A node must not transmit frames containing higher-layer >>>> packets until the node has successfully joined a network. >>>>=20 >>>> Frames generated by the IEEE 802.15.4 layer are transmitted >>>> before frames containing higher-layer packets. >>>>=20 >>>> Frame types BEACON and COMMAND are transmitted before frame >> types >>>> DATA and ACK. >>>>=20 >>>> A node has to be prepared to send a BEACON or COMMAND frame at >> any >>>> time. >>>>=20 >>>> I've tried to infer the desired behavior from the description >>>> of queue >> usage. >>>> If I understand the original text correctly, there is no >>>> difference between the second and third requirements. >>>>=20 >>>> 11. According to [I-D.ietf-6tisch-terminology], the correct >>>> term is "timeslot", so s/time slot/timeslot/ throughout the >>>> document. >>>>=20 >>>> 12. In the table at the top of page 4 (BTW, please number and >>>> add a title to all tables), are the listed properties the only >>>> properties that have numeric or short text string values? If >>>> not, all of those properties should be gathered together into a >>>> single table. As an editorial aside, this table is pretty much >>>> what I expected to be the bulk >> of this document. >>>>=20 >>>> 13. Even if the number of timeslots in a slotframe is variable >>>> for this minimal configuration, should there be a default? >>>>=20 >>>> 14. In the table at the top of page 5, what do the empty boxes >> represent? >>>>=20 >>>> 15. The last sentence of section 3.2 seems to be a low-level=20 >>>> implementation detail that can be omitted. >>>>=20 >>>> 16. Without having read the IEEE 802.15.4 docs recently to >>>> confirm, I'll suggest that almost all of section 3.4 is a >>>> restatement of the IEEE 802.15.4 spec. The last sentence is >>>> important, and isn't entirely clear. It would be clearer to >>>> write: >>>>=20 >>>> For the minimal configuration specified in this document, the >>>> use of CCA is OPTIONAL. >>>>=20 >>>> 17. End of section 3 - not clear when to use >>>> macTimeslotTemplate. >>>>=20 >>>> 18. The third paragraph of section 4 is completely unclear to >>>> me: >>>>=20 >>>> A Node aiming to join the network by receving a properly >>>> formed BEACON shall enter in a scan phase and shall store the >>>> value of macPANId and then set it to 0xffff for the duration of >>>> the scan in order to meet the filtering rules in [IEEE802154]. >>>>=20 >>>> What are "macPANId" and "scan phase"? I don't see those terms >>>> used anywhere else in this document; do the terms come from the >>>> IEEE 802.15.4 specs? Why would an implementation store the >>>> value of macPANId and then set it to 0xffff? >>>>=20 >>>> 19. Does "synchronization" in section 5 mean "time >>>> synchronization"? >>>>=20 >>>> 20. In section 5, is "EB_PERIOD" the same value as defined in >>>> the table in section 10.2.4 that defines "RPL-related >>>> variables"? If so, I don't understand why "EB_PERIOD" is in >>>> that table, as it only appears once in the rest of the document >>>> in section 5. >>>>=20 >>>> 21. I see that section 10 includes the statement: >>>>=20 >>>> Nodes in a multihop network MUST use the RPL routing protocol=20 >>>> [RFC6550]. >>>>=20 >>>> This statement is certainly false if one takes a broad >>>> definition of the word "multihop". Even if edited to >>>> "multilink subnet" or "mesh", I can't find any support in RFC >>>> 6550 for the statement "MUST use RPL routing protocol". I >>>> think it would be much clearer and more correct to quote >>>> verbatim the text describing this requirement from RFC 6550=20 >>>> rather than paraphrasing it here. >>>>=20 >>>> Similarly, this sentence in section 10.1 needs, at least, to >>>> be edited, and I think it should be replaced with quoted text >>>> from RFC 6552. >>>>=20 >>>> Nodes in the multihop network MUST implement the RPL Objective=20 >>>> Function Zero [RFC6552]. >>>>=20 >>>> While I haven't provided a detailed review of the remainder of=20 >>>> section 10 because I don't think it's necessary for the goals >>>> of this document, it appears to me that much of section 10 is a >>>> restatement of the RPL specification from RFC 6550 and should, >>>> therefore, be omitted (if RPL is retained as a part of this >>>> recommendation). >>>=20 --7OumEuPsRHxuqQf09recvgOGTTtEqXHRH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWNYVAAAoJEBOZRqCi7goqK1kIAIkZ0STu3PfgEOYDV4Eyqil1 b7LXxJHLQmQsNexajrNZmVXLT5TC3DIz2mZA0usH4rj7BM62n4oA7HWVA4oKdWD+ X9OwzLXhGmCTH0tsMzFyVuuKgmps0mVSnbZo15qxTSa7L1btWAr49fyFqASHV9/D tYX80zEbWQP2Kaoe1aukGakcCMAUsmzdxlbFLEyGbkgK1K4i0TWPUqIV8u1XNEul z64Sn3ZWmXgCQ3cnI6qtRCORXIxa3R0uuSvpfB9xTgiA0lNJKXZgPMKSketHKrE2 OuuI9GPPEvCVKNgozIgKu48UjRJEAr2c7XpEeyz8elwkY6SI6sGYXl7ZeoOlx4A= =32Yn -----END PGP SIGNATURE----- --7OumEuPsRHxuqQf09recvgOGTTtEqXHRH--