From jdrake@juniper.net Wed Sep 1 05:52:43 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B3D3A6A37 for ; Wed, 1 Sep 2010 05:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUNojI4P2VEY for ; Wed, 1 Sep 2010 05:52:19 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id CD91E3A695B for ; Wed, 1 Sep 2010 05:52:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTH5MmibvB1BYfDQDbylRYJx509KLe11d@postini.com; Wed, 01 Sep 2010 05:52:47 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 1 Sep 2010 05:43:44 -0700 From: John E Drake To: "rtg-ads@tools.ietf.org" Date: Wed, 1 Sep 2010 05:43:38 -0700 Thread-Topic: RtgDir review: draft-ietf-ccamp-gmpls-ethernet-pbb-te Thread-Index: ActJ00znKHUAlLu3R16Lhtq2eE1rDQ== Message-ID: <5E893DB832F57341992548CDBB333163984B6FCCAC@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {95F9248D-6610-4419-B091-2C40EDBCE1C1} x-cr-hashedpuzzle: AcYa BWjS BX3r CLhP DX6g ETeb Ey5+ FMwJ F2d/ HnvM JJ0w JN9j KmI+ M5/a OHiO UhUV; 2; cgB0AGcALQBhAGQAcwBAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AHIAdABnAC0AZABpAHIAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {95F9248D-6610-4419-B091-2C40EDBCE1C1}; agBkAHIAYQBrAGUAQABqAHUAbgBpAHAAZQByAC4AbgBlAHQA; Wed, 01 Sep 2010 12:43:38 GMT; UgB0AGcARABpAHIAIAByAGUAdgBpAGUAdwA6ACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGcAbQBwAGwAcwAtAGUAdABoAGUAcgBuAGUAdAAtAHAAYgBiAC0AdABlAA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-ethernet-pbb-te X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 12:52:44 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://www.ietf.org/iesg/directorate/= routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-gmpls-ethernet-pbb-te Reviewer: John Drake=20 Review Date: 01 September 2010=20 IETF LC End Date: 01 September 2010=20 Intended Status: Proposed Standard Summary:=20 The document is well written but suffers from an over-abundance of unnecess= ary detail. Comments:=20 This document could be made more understandable by removing the material in= section 2.1 and 3 describing the internal structure of a Backbone Edge Bri= dge. Most of it is irrelevant to the operation of the GMPLS control plane = and the description of internal components, particularly those that are not= externally visible, is not typically useful. Examples describing how ESP-VID and ESP-MAC DA are obtained would also be h= elpful. From akr@cisco.com Wed Sep 1 23:38:20 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8813A695B for ; Wed, 1 Sep 2010 23:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz6fsBvySK4C for ; Wed, 1 Sep 2010 23:38:09 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1A1863A6A72 for ; Wed, 1 Sep 2010 23:37:47 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGPjfkxAaMHG/2dsb2JhbACBRJ84caF4nA2FOQSEQYVY X-IronPort-AV: E=Sophos;i="4.56,307,1280707200"; d="scan'208,217";a="248632833" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 02 Sep 2010 06:38:10 +0000 Received: from sjc-vpn6-1864.cisco.com (sjc-vpn6-1864.cisco.com [10.21.127.72]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o826c78M018658; Thu, 2 Sep 2010 06:38:08 GMT Message-ID: <4C7F464F.6030808@cisco.com> Date: Wed, 01 Sep 2010 23:38:07 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary="------------000809020002040000080505" Cc: rtg-dir@ietf.org, draft-ietf-roll-rpl.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-roll-rpl-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 06:38:20 -0000 This is a multi-part message in MIME format. --------------000809020002040000080505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-roll-rpl-11.txt Reviewer: Abhay Roy Review Date: 1st September 2010 IETF LC End Date: 1st September 2010 Intended Status: Proposed Standard *Summary:* I have some major issues with this document that needs be resolved before publication. *Comments:* This is a very thoroughly written document and attempts to solve a large number of scenario's in ROLL problem statement. I only had two weeks to go over this 130+ pages long draft. So my review (especially on finer protocol state machines) is not sufficiently in-depth. *Major Issues:* This is a pretty complex protocol with a lot of intricate rules to hold it all together. It's vital that the correctness of many of these state machines be proven by requiring 2 (or more) interoperable implementations as a prerequisite for it becoming a Proposed Standard. There is a normative reference to draft-ietf-roll-trickle-02, which is an Informational track document. This is generally not allowed. Any reason why this is being done here? This document requires use of an Objective Function, but none have been defined in the draft. There is an Informative reference to draft-ietf-roll-of0-03 (why not Normative?). Ideally, at least one OF should have been defined in this document with an option to define additional ones in time. Section 6.2.1" "Format of the DIS Base Object 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: The DIS Base Object Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver." #### This document doesn't allocate any bit from the Flags and Reserved fields. I chose this message just to cite an example. There are similar fields in other messages which are unused. I can understand leaving a few bits aside for future proofing. But having two 8 bit fields next to each other, and both completely unassigned, doesn't make much sense. Any rationale here? Section 6.6: "A CC message (request or response) MUST NOT set the 'C' bit of the security section: CC messages always have full counters." #### I can't seem to find the C bit in security section. *Minor Issues:* It's not clear on what should happen if state being stored in storing-mode "overflows", i.e. a node can't quite keep all the state.I may have missed it. In routing problems, it's important that the routing behavior is described in cases where an intermediate node doesn't have full state. Section 3.3.2: "A DODAG Root institutes a global repair operation by incrementing the DODAG Version Number." ### What are the event based trigger to cause this? Section 3.3.7: "For example, if a node receives a packet flagged as moving in the upward direction, and if that packet records that the transmitter is of a lower (lesser) Rank than the receiving node, then the receiving node is able to conclude that the packet has not progressed in the upward direction and that the DODAG is inconsistent. " ### Doing such checks in hardware forwarding paths isn't exactly trivial. Is the assumption here that the packet forwarding rate is low, and hence software forwarding path is good enough? Section 3.6.2: "DAGRank(M) equals DAGRank(N): In this case the positions of M and N within the DODAG and with respect to the DODAG root are similar (identical). Routing through a node with equal Rank may cause a routing loop (i.e., if that node chooses to route through a node with equal Rank as well). ### Does this mean, one can't route "upwards" via another node of the same rank? Wouldn't think cause black holes in some scenarios where that might be the only viable path left? Section 3.8.1.1: ### Nice example of nodes B and C both trying to get 2 parents. But I am not sure, if the spec is crisp in terms of what are the rules to avoid it. Section 3.8.3: "This loop happens when a No-Path (a DAO message that invalidates a previously announced prefix) was missed and persists until all state has been cleaned up." ### What is the trigger to cleanup old stale state? Section 3.8.3: RPL includes loop detection mechanisms that may mitigate the impact of DAO loops and trigger their repair. ### May? Shouldn't this be a more stronger statement? Loops are bad ;) There are a lot of usage of variable size values using TLV encoding. The authors have chosen an 8 bit field for length. It ends up limiting to 256 bytes of payload. In many other protocols, this has become a "limitation" in the long run. Just wanted to bring to your attention, if you see a need arising for bigger payloads. *Nits:* none --------------000809020002040000080505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit


Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-roll-rpl-11.txt
Reviewer: Abhay Roy
Review Date: 1st September 2010
IETF LC End Date: 1st September 2010
Intended Status: Proposed Standard

Summary:
I have some major issues with this document that needs be resolved before publication.

Comments:
This is a very thoroughly written document and attempts to solve a large number of scenario's in ROLL problem statement. I only had two weeks to go over this 130+ pages long draft. So my review (especially on finer protocol state machines) is not sufficiently in-depth.

Major Issues:

This is a pretty complex protocol with a lot of intricate rules to hold it all together. It's vital that the correctness of many of these state machines be proven by requiring 2 (or more) interoperable implementations as a prerequisite for it becoming a Proposed Standard.

There is a normative reference to draft-ietf-roll-trickle-02, which is an Informational track document. This is generally not allowed. Any reason why this is being done here?

This document requires use of an Objective Function, but none have been defined in the draft. There is an Informative reference to  draft-ietf-roll-of0-03 (why not Normative?). Ideally, at least one OF should have been defined in this document with an option to define additional ones in time.

Section 6.2.1"
"Format of the DIS Base Object

        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |   Reserved    |   Option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 13: The DIS Base Object

   Flags:  8-bit unused field reserved for flags.  The field MUST be
         initialized to zero by the sender and MUST be ignored by the
         receiver.

   Reserved:  8-bit unused field.  The field MUST be initialized to zero
         by the sender and MUST be ignored by the receiver."

#### This document doesn't allocate any bit from the Flags and Reserved fields. I chose this message just to cite an example. There are similar fields in other messages which are unused. I can understand leaving a few bits aside for future proofing. But having two 8 bit fields next to each other, and both completely unassigned, doesn't make much sense. Any rationale here?

Section 6.6:
"A CC message (request or response) MUST NOT set the 'C' bit of the security section: CC messages always have full counters."

#### I can’t seem to find the C bit in security section.

Minor Issues:

It’s not clear on what should happen if state being stored in storing-mode “overflows”, i.e. a node can’t quite keep all the state.I may have missed it. In routing problems, it's important that the routing behavior is described in cases where an intermediate node doesn't have full state.


Section 3.3.2:
"A DODAG Root institutes a global repair operation by incrementing the DODAG Version Number."


### What are the event based trigger to cause this?


Section 3.3.7:
"For example, if a node receives a packet flagged as moving in the  upward direction, and if that packet records that the transmitter is of a lower (lesser) Rank than the receiving node, then the receiving node is able to conclude that the packet has not progressed in the upward direction and that the DODAG is inconsistent. "


### Doing such checks in hardware forwarding paths isn’t exactly trivial. Is the assumption here that the packet forwarding rate is low, and hence software forwarding path is good enough?


Section 3.6.2:
"DAGRank(M) equals DAGRank(N):  In this case the positions of M and N within the DODAG and with respect to the DODAG root are similar (identical).  Routing through a node with equal Rank may cause a routing loop (i.e., if that node chooses to route through a node with equal Rank as well).

### Does this mean, one can’t route “upwards” via another node of the same rank? Wouldn’t think cause black holes in some scenarios where that might be the only viable path left?

Section 3.8.1.1:


### Nice example of nodes B and C both trying to get 2 parents. But I am not sure, if the spec is crisp in terms of what are the rules to avoid it.


Section 3.8.3:
"This loop happens when a No-Path (a DAO message that invalidates a previously announced prefix) was missed and persists until all state has been cleaned up."

### What is the trigger to cleanup old stale state?



Section 3.8.3:
RPL includes loop detection mechanisms that may mitigate the impact of  DAO loops and trigger their repair.

### May? Shouldn’t this be a more stronger statement? Loops are bad ;)


There are a lot of usage of variable size values using TLV encoding. The authors have chosen an 8 bit field for length.  It ends up limiting to 256 bytes of payload. In many other protocols, this has become a “limitation” in the long run. Just wanted to bring to your attention, if you see a need arising for bigger payloads.

Nits:
none

--------------000809020002040000080505-- From russ@cisco.com Tue Sep 7 10:05:03 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195213A6A3F for ; Tue, 7 Sep 2010 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATLQ6ZT4nE1S for ; Tue, 7 Sep 2010 10:05:01 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id ACD2C3A6A76 for ; Tue, 7 Sep 2010 10:05:01 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQGAKUNhkxAZnwN/2dsb2JhbACDGJAxjSpxpDqJdQiRNoRFeASKGA X-IronPort-AV: E=Sophos;i="4.56,329,1280707200"; d="asc'?scan'208";a="156372228" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Sep 2010 17:05:29 +0000 Received: from [127.0.0.1] (rtp-russwh-8712.cisco.com [10.116.137.179]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o87H5TpQ003691; Tue, 7 Sep 2010 17:05:29 GMT Message-ID: <4C8670D9.9080900@cisco.com> Date: Tue, 07 Sep 2010 13:05:29 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig71816823919414AF7D613AD0" Cc: rtg-dir@ietf.org, draft-ietf-pce-p2mp-reqs.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-opsec-igp-crypto-requirements-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 17:05:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig71816823919414AF7D613AD0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsec-igp-crypto-requirements-00.txt Reviewer: Manav Bhatia, Vishwas Manra Review Date: 25 January 2010 IETF LC End Date: 5 September 2010 Intended Status: Informational Summary: I have no concerns with this draft moving forward. Comments: This document describes the problems being addressed, and the mechanisms chosen to address them, well. The algorithms are well chosen, and the reason for choosing these algorithms is well laid out for the reader. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: No nits found. Russ --------------enig71816823919414AF7D613AD0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyGcNkACgkQER27sUhU9OTzRwCfQGtabqOO7UR4UU16BZeKt0R8 U5sAn35BQ5KHz0yTUyxLCTZ+982KHO3j =SJZf -----END PGP SIGNATURE----- --------------enig71816823919414AF7D613AD0-- From wintert@acm.org Mon Sep 13 13:53:19 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D803A6AC5 for ; Mon, 13 Sep 2010 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.736 X-Spam-Level: X-Spam-Status: No, score=-100.736 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6YlrmNxTptx for ; Mon, 13 Sep 2010 13:53:17 -0700 (PDT) Received: from smtp101.prem.mail.ac4.yahoo.com (smtp101.prem.mail.ac4.yahoo.com [76.13.13.40]) by core3.amsl.com (Postfix) with SMTP id 853463A6ABD for ; Mon, 13 Sep 2010 13:53:12 -0700 (PDT) Received: (qmail 58066 invoked from network); 13 Sep 2010 20:53:30 -0000 Received: from [192.168.47.104] (wintert@206.83.249.194 with plain) by smtp101.prem.mail.ac4.yahoo.com with SMTP; 13 Sep 2010 13:53:29 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 48XKU.gVM1kMmQ8tAOBVFTahgFo7LlA3P4Msif8CSOCHvBa c4G3UicIEInAKnSHB9Y3JZuYwE53LpsSwkC2.oyHC7LD_vDEVzaTIo4l7BAJ CHc6ECIoii9Cb7KHP438vdtiy.JmPb9j73ojgR6b5Z2llRfop.9gzIU_XlZB iBHFvn_Qxt9zNnoYYoGMnkPubHdzFGWj5yOAiBpLjABa22nGrGNBeWTZ_5Vr eR.k6jJnJ3HeNoXewU_53oe_Bp3xXDVAfinK_xb06nBFY.F8e6LPqjcMZbPr obNL1ajOD2z_KMuYxyjyV.t_fUJf9GMFqscpy2q_Jn7DLLkMLoLh5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C8E8F45.3010203@acm.org> Date: Mon, 13 Sep 2010 16:53:25 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100826 Thunderbird/3.0.7 MIME-Version: 1.0 To: Abhay Roy References: <4C7F464F.6030808@cisco.com> In-Reply-To: <4C7F464F.6030808@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 13 Sep 2010 15:14:26 -0700 Cc: rtg-dir@ietf.org, draft-ietf-roll-rpl.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-roll-rpl-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 20:53:20 -0000 Hi Abhay, On 09/02/2010 02:38 AM, Abhay Roy wrote: > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. Thank you for your review -- we will strive to resolve them. > > Document: draft-ietf-roll-rpl-11.txt > Reviewer: Abhay Roy > Review Date: 1st September 2010 > IETF LC End Date: 1st September 2010 > Intended Status: Proposed Standard > > *Summary:* > I have some major issues with this document that needs be resolved > before publication. > > *Comments:* > This is a very thoroughly written document and attempts to solve a large > number of scenario's in ROLL problem statement. I only had two weeks to > go over this 130+ pages long draft. So my review (especially on finer > protocol state machines) is not sufficiently in-depth. > > *Major Issues:* > > This is a pretty complex protocol with a lot of intricate rules to hold > it all together. It's vital that the correctness of many of these state > machines be proven by requiring 2 (or more) interoperable > implementations as a prerequisite for it becoming a Proposed Standard. There are 10+ known implementations. Interoperability events coordinated by the IP for Smart Objects Alliance (IPSO) and the Zigbee Alliance have taken place and both were successful. Although the results were not public, we did have positive feedback, and both the storing and non-storing modes have been tested. We cannot guarantee that ALL features have been tested, but certainly a good number of them thus far. > > There is a normative reference to draft-ietf-roll-trickle-02, which is > an Informational track document. This is generally not allowed. Any > reason why this is being done here? The WG has moved draft-ietf-roll-trickle to Standards Track to resolve this issue, and a publication request has been made. > > This document requires use of an Objective Function, but none have been > defined in the draft. There is an Informative reference to > draft-ietf-roll-of0-03 (why not Normative?). Ideally, at least one OF > should have been defined in this document with an option to define > additional ones in time. We explicitly did not intend to bind the implementer to use a particular objective function, or to include objective functions in the RPL base specification. It was thought that this would enforce that the RPL base specification could be flexible with regard to supporting a range of objectives. In fact, the WG did decide that not even a 'default' OF should be mandated. It is further expected that a given SDO such as Zigbee or ISA100 will define its own OF as part of the package. > > Section 6.2.1" > "Format of the DIS Base Object > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Reserved | Option(s)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: The DIS Base Object > > Flags: 8-bit unused field reserved for flags. The field MUST be > initialized to zero by the sender and MUST be ignored by the > receiver. > > Reserved: 8-bit unused field. The field MUST be initialized to zero > by the sender and MUST be ignored by the receiver." > > #### This document doesn't allocate any bit from the Flags and Reserved > fields. I chose this message just to cite an example. There are similar > fields in other messages which are unused. I can understand leaving a > few bits aside for future proofing. But having two 8 bit fields next to > each other, and both completely unassigned, doesn't make much sense. Any > rationale here? We do anticipate future follow-on work to this RPL base specification that will make use of those flag fields, and we did desire to open those IANA registries at this time to administer those flags. In this particular case, as a direct result of Ticket 71, the WG is considering some explicit follow-up work to RPL that will make use/allocate from the DIS Flags field. > > Section 6.6: > "A CC message (request or response) MUST NOT set the 'C' bit of the > security section: CC messages always have full counters." > > #### I can’t seem to find the C bit in security section. This text is an editorial mistake and will be removed. The 'C' bit refers to a mode of operation where the Counter field could be compressed, and was removed in WG discussion. > > *Minor Issues:* > > It’s not clear on what should happen if state being stored in > storing-mode “overflows”, i.e. a node can’t quite keep all the state.I > may have missed it. In routing problems, it's important that the routing > behavior is described in cases where an intermediate node doesn't have > full state. This was discussed in the WG -- the intention of the RPL base spec is to suggest that nodes in storing-mode deployments should be properly scaled to handle the size of the network segments that they will encounter. This is consistent with proprietary practices deployed today. Future specifications may elaborate on more refined actions/behaviors to manage this case. As it stands today, if an intermediate node cannot accommodate full state then the routing state is not complete and messages may be dropped, similar to what other protocols do today. We can add a sentence to clarify this intent, and to point to the possibility of future work. > > > Section 3.3.2: > "A DODAG Root institutes a global repair operation by incrementing the > DODAG Version Number." > > > ### What are the event based trigger to cause this? This is declared to be application/implementation specific and out of scope. RPL defines how to trigger the global repair, but leaves it to the implementation to figure out when it is necessary. This is in part because global repair in an LLN may be very expensive and we did not want to mandate how and when it is invoked in the RPL base. Section 17.2.5 and 17.5 also elaborate as follows: 17.2.5. Parameters to be configured on the DODAG root ... DAG Version Number Increment: a RPL implementation may allow by configuration at the DODAG root to refresh the DODAG states by updating the DODAGVersionNumber. A RPL implementation SHOULD allow configuring whether or not periodic or event triggered mechanisms are used by the DODAG root to control DODAGVersionNumber change (which triggers a global repair as specified in Section 3.3.2. ... 17.5. Fault Management Fault management is a critical component used for troubleshooting, verification of the correct mode of operation of the protocol, network design, and is also a key component of network performance monitoring. A RPL implementation SHOULD allow providing the following information related to fault managements: o Memory overflow along with the cause (e.g. routing tables overflow, ...) o Number of times a packet could not be sent to a DODAG parent flagged as valid o Number of times a packet has been received for which the router did not have a corresponding RPLInstanceID o Number of times a local repair procedure was triggered o Number of times a global repair was triggered by the DODAG root > > > Section 3.3.7: > "For example, if a node receives a packet flagged as moving in the > upward direction, and if that packet records that the transmitter is of > a lower (lesser) Rank than the receiving node, then the receiving node > is able to conclude that the packet has not progressed in the upward > direction and that the DODAG is inconsistent. " > > > ### Doing such checks in hardware forwarding paths isn’t exactly > trivial. Is the assumption here that the packet forwarding rate is low, > and hence software forwarding path is good enough? In general, today, it is the case that most LLN technologies are limited more so by communication bandwidth than by processing bandwidth, i.e. that software in general can easily keep up with the link layer. But we do not intend to assume this in the design of RPL, and that RPL should be applicable for other future technologies. More specifically, it is known in the art and practice that 'forwarding-time' inconsistency detection is a useful technique for LLNs. Such a detection technique does require this type of checking to be done by the receiving node. (Note that in our response to GenART comments we do intend to add a few more informative references to give additional background to this rationale) We would then expect that any future LLN implementation that did include HW for the forwarding logic would have to accommodate this non-trivial check. > > > Section 3.6.2: > "DAGRank(M) equals DAGRank(N): In this case the positions of M and N > within the DODAG and with respect to the DODAG root are similar > (identical). Routing through a node with equal Rank may cause a routing > loop (i.e., if that node chooses to route through a node with equal Rank > as well). > > ### Does this mean, one can’t route “upwards” via another node of the > same rank? Wouldn’t think cause black holes in some scenarios where that > might be the only viable path left? That is true. This concept was denoted 'sibling' forwarding in the WG (note the broad interpretation of 'sibling' as 'nodes of the same Rank' does not necessarily imply common parents), and was explicitly ruled out by the WG in favor of a more simplified/streamlined base specification (Ticket 43). It is expected that this concept will be elaborated/explored further in future work. > > Section 3.8.1.1: > > > ### Nice example of nodes B and C both trying to get 2 parents. But I am > not sure, if the spec is crisp in terms of what are the rules to avoid it. In this example it is our attempt to give a general illustration of how greedy behavior can lead to loops/instabilities. At the end of the example we do attempt to summarize the mechanisms RPL takes as follows: o This cycle can be averted through mechanisms in RPL: * Nodes (B) and (C) stay at a rank sufficient to attach to their most preferred parent (A) and don't go for any deeper (worse) alternate parents (Nodes are not greedy) * Nodes (B) and (C) do not process DIO messages from nodes deeper than themselves (because such nodes are possibly in their own sub-DODAGs) We could further clarify by adding a reference from this example to the rules in Section 8.2.2.4, which serve to bound the impact greedy behavior while allowing limited movement for local repair: 8.2.2.4. Rank and Movement within a DODAG Version ... 2. A node MAY advertise a Rank lower than its prior advertisement within the DODAG Version. 3. Let L be the lowest rank within a DODAG Version that a given node has advertised. Within the same DODAG Version, that node MUST NOT advertise an effective rank higher than L + DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule: a node MAY advertise an INFINITE_RANK within a DODAG version without restriction. If a node's Rank were to be higher than allowed by L + DAGMaxRankIncrease, when it advertises Rank it MUST advertise its Rank as INFINITE_RANK. ... Conceptually, an implementation is maintaining a DODAG parent set within the DODAG Version. Movement entails changes to the DODAG parent set. Moving Up does not present the risk to create a loop but moving Down might, so that operation is subject to additional constraints. ... A node is allowed to join any DODAG Version that it has never been a prior member of without any restrictions, but if the node has been a prior member of the DODAG Version then it must continue to observe the rule that it may not advertise an effective rank higher than L+DAGMaxRankIncrease at any point in the life of the DODAG Version. This rule must be observed so as not to create a loophole that would allow the node to effectively increment its rank all the way to INFINITE_RANK, which may have impact on other nodes and create a resource-wasting count-to-infinity scenario. > > > Section 3.8.3: > "This loop happens when a No-Path (a DAO message that invalidates a > previously announced prefix) was missed and persists until all state has > been cleaned up." > > ### What is the trigger to cleanup old stale state? Generally this will be triggered by inconsistency detection as that forwarding path is attempted and fails. This is covered in Section 11.2, more specifically in Section 11.2.2.3: 11.2.2.3. DAO Inconsistency Loop Detection and Recovery A DAO inconsistency happens when a router has a downward route that was previously learned from a DAO message via a child, but that downward route is not longer valid in the child, e.g. because that related state in the child has been cleaned up. With DAO inconsistency loop recovery, a packet can be used to recursively explore and cleanup the obsolete DAO states along a sub-DODAG. In a general manner, a packet that goes Down should never go Up again. If DAO inconsistency loop recovery is applied, then the router SHOULD send the packet back to the parent that passed it with the Forwarding-Error 'F' bit set and the 'O' bit left untouched. Otherwise the router MUST silently discard the packet. We can add a reference to Section 11.2 from Section 3.8.3 to help make this clear for the reader. > > > > Section 3.8.3: > RPL includes loop detection mechanisms that may mitigate the impact of > DAO loops and trigger their repair. > > ### May? Shouldn’t this be a more stronger statement? Loops are bad ;) The problem with a stronger statement is that RPL does not guarantee loop freedom. In practice strict loop avoidance is costly and difficult to achieve in LLNs. RPL's approach tries to avoid the construction of topologies that contain loops, further allows to detect a loop by the detection of inconsistencies in a packet flow, and then to initiate a repair. We could strike the 'may', since loop detection does certainly mitigate the impact of DAO loops (even though that mitigation may not be 100% effective). Prior to the text that you noted, in Section 3.8, we do say: 3.8. Loop Avoidance RPL avoids creating loops when undergoing topology changes and includes rank-based datapath validation mechanisms for detecting loops when they do occur (see Section 11 for more details). In practice, this means that RPL guarantees neither loop free path selection nor tight delay convergence times, but can detect and repair a loop as soon as it is used. RPL uses this loop detection to ensure that packets make forward progress within the DODAG Version and trigger repairs when necessary. > > > There are a lot of usage of variable size values using TLV encoding. The > authors have chosen an 8 bit field for length. It ends up limiting to > 256 bytes of payload. In many other protocols, this has become a > “limitation” in the long run. Just wanted to bring to your attention, if > you see a need arising for bigger payloads. Noted. 8-bit length fields are thought to be sufficient for the majority of the RPL options. In the case of the Metric Container, which may exceed 256 bytes, we did adopt the following convention in Section 6.7.4, which could be carried forward to other options if needed: 6.7.4. Metric Container ... The Metric Container MAY appear more than once in the same RPL control message, for example to accommodate a use case where the Metric Data is longer than 256 bytes. More information is in [I-D.ietf-roll-routing-metrics]. > > *Nits:* > none Did we address your concerns? Regards, -RPL Authors From akr@cisco.com Wed Sep 15 23:31:34 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441203A68AB for ; Wed, 15 Sep 2010 23:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.999 X-Spam-Level: X-Spam-Status: No, score=-107.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rAzvvd+vBJY for ; Wed, 15 Sep 2010 23:31:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 12FB73A6868 for ; Wed, 15 Sep 2010 23:31:32 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL5WkUyrR7Hu/2dsb2JhbAChdnGmYJxLhUEEhEqFYg X-IronPort-AV: E=Sophos;i="4.56,375,1280707200"; d="scan'208";a="590048743" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 16 Sep 2010 06:31:57 +0000 Received: from sjc-vpn4-577.cisco.com (sjc-vpn4-577.cisco.com [10.21.82.65]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8G6VvJ7011081; Thu, 16 Sep 2010 06:31:57 GMT Message-ID: <4C91B9DC.30904@cisco.com> Date: Wed, 15 Sep 2010 23:31:56 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Tim Winter References: <4C7F464F.6030808@cisco.com> <4C8E8F45.3010203@acm.org> In-Reply-To: <4C8E8F45.3010203@acm.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rtg-dir@ietf.org, draft-ietf-roll-rpl.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-roll-rpl-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 06:31:34 -0000 Hi Tim (and other RPL Authors), Thanks for taking the time for the elaborate explanations for the issues raised. With the suggested edits/clarifications below, I have no further concerns. Once again, it was a joy to review such a comprehensive draft! Regards, -Abhay On 9/13/10 1:53 PM, Tim Winter wrote: > Hi Abhay, > > On 09/02/2010 02:38 AM, Abhay Roy wrote: > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this > draft. > > The Routing Directorate seeks to review all routing or routing-related > > drafts as they pass through IETF last call and IESG review. The purpose > > of the review is to provide assistance to the Routing ADs. For more > > information about the Routing Directorate, please see > > http://www.ietf.org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the Routing > ADs, it > > would be helpful if you could consider them along with any other IETF > > Last Call comments that you receive, and strive to resolve them through > > discussion or by updating the draft. > > Thank you for your review -- we will strive to resolve them. > > > > > > > Document: draft-ietf-roll-rpl-11.txt > > Reviewer: Abhay Roy > > Review Date: 1st September 2010 > > IETF LC End Date: 1st September 2010 > > Intended Status: Proposed Standard > > > > *Summary:* > > I have some major issues with this document that needs be resolved > > before publication. > > > > *Comments:* > > This is a very thoroughly written document and attempts to solve a > large > > number of scenario's in ROLL problem statement. I only had two weeks to > > go over this 130+ pages long draft. So my review (especially on finer > > protocol state machines) is not sufficiently in-depth. > > > > *Major Issues:* > > > > This is a pretty complex protocol with a lot of intricate rules to hold > > it all together. It's vital that the correctness of many of these state > > machines be proven by requiring 2 (or more) interoperable > > implementations as a prerequisite for it becoming a Proposed Standard. > > There are 10+ known implementations. Interoperability events coordinated > by the IP for Smart Objects Alliance (IPSO) and the Zigbee Alliance have > taken place and both were successful. Although the results were not > public, we did have positive feedback, and both the storing and > non-storing > modes have been tested. We cannot guarantee that ALL features have been > tested, but certainly a good number of them thus far. > > > > > > > There is a normative reference to draft-ietf-roll-trickle-02, which is > > an Informational track document. This is generally not allowed. Any > > reason why this is being done here? > > The WG has moved draft-ietf-roll-trickle to Standards Track to resolve > this issue, and a publication request has been made. > > > > > > > This document requires use of an Objective Function, but none have been > > defined in the draft. There is an Informative reference to > > draft-ietf-roll-of0-03 (why not Normative?). Ideally, at least one OF > > should have been defined in this document with an option to define > > additional ones in time. > > We explicitly did not intend to bind the implementer to use a particular > objective function, or to include objective functions in the RPL base > specification. It was thought that this would enforce that the RPL base > specification could be flexible with regard to supporting a range of > objectives. In fact, the WG did decide that not even a 'default' OF > should > be mandated. It is further expected that a given SDO such as Zigbee or > ISA100 will define its own OF as part of the package. > > > > > > > Section 6.2.1" > > "Format of the DIS Base Object > > > > 0 1 2 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Flags | Reserved | Option(s)... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 13: The DIS Base Object > > > > Flags: 8-bit unused field reserved for flags. The field MUST be > > initialized to zero by the sender and MUST be ignored by the > > receiver. > > > > Reserved: 8-bit unused field. The field MUST be initialized to zero > > by the sender and MUST be ignored by the receiver." > > > > #### This document doesn't allocate any bit from the Flags and Reserved > > fields. I chose this message just to cite an example. There are similar > > fields in other messages which are unused. I can understand leaving a > > few bits aside for future proofing. But having two 8 bit fields next to > > each other, and both completely unassigned, doesn't make much sense. > Any > > rationale here? > > We do anticipate future follow-on work to this RPL base specification > that > will make use of those flag fields, and we did desire to open those IANA > registries at this time to administer those flags. In this particular > case, > as a direct result of Ticket 71, the WG is considering some explicit > follow-up work to RPL that will make use/allocate from the DIS Flags > field. > > > > > > > Section 6.6: > > "A CC message (request or response) MUST NOT set the 'C' bit of the > > security section: CC messages always have full counters." > > > > #### I can’t seem to find the C bit in security section. > > This text is an editorial mistake and will be removed. The 'C' bit > refers > to a mode of operation where the Counter field could be compressed, > and was > removed in WG discussion. > > > > > > > *Minor Issues:* > > > > It’s not clear on what should happen if state being stored in > > storing-mode “overflows”, i.e. a node can’t quite keep all the state.I > > may have missed it. In routing problems, it's important that the > routing > > behavior is described in cases where an intermediate node doesn't have > > full state. > > This was discussed in the WG -- the intention of the RPL base spec is to > suggest that nodes in storing-mode deployments should be properly > scaled to > handle the size of the network segments that they will encounter. > This is > consistent with proprietary practices deployed today. Future > specifications may elaborate on more refined actions/behaviors to manage > this case. > > As it stands today, if an intermediate node cannot accommodate full state > then the routing state is not complete and messages may be dropped, > similar > to what other protocols do today. > > We can add a sentence to clarify this intent, and to point to the > possibility of future work. > > > > > > > > > Section 3.3.2: > > "A DODAG Root institutes a global repair operation by incrementing the > > DODAG Version Number." > > > > > > ### What are the event based trigger to cause this? > > This is declared to be application/implementation specific and out of > scope. RPL defines how to trigger the global repair, but leaves it to > the > implementation to figure out when it is necessary. This is in part > because > global repair in an LLN may be very expensive and we did not want to > mandate how and when it is invoked in the RPL base. Section 17.2.5 and > 17.5 also elaborate as follows: > > > 17.2.5. Parameters to be configured on the DODAG root > > ... > > DAG Version Number Increment: a RPL implementation may allow by > configuration at the DODAG root to refresh the DODAG states by > updating the DODAGVersionNumber. A RPL implementation SHOULD > allow > configuring whether or not periodic or event triggered mechanisms > are used by the DODAG root to control DODAGVersionNumber change > (which triggers a global repair as specified in Section 3.3.2. > > ... > > 17.5. Fault Management > > Fault management is a critical component used for troubleshooting, > verification of the correct mode of operation of the protocol, > network > design, and is also a key component of network performance > monitoring. A RPL implementation SHOULD allow providing the > following information related to fault managements: > > o Memory overflow along with the cause (e.g. routing tables > overflow, ...) > > o Number of times a packet could not be sent to a DODAG parent > flagged as valid > > o Number of times a packet has been received for which the router > did not have a corresponding RPLInstanceID > > o Number of times a local repair procedure was triggered > > o Number of times a global repair was triggered by the DODAG root > > > > > > > > > Section 3.3.7: > > "For example, if a node receives a packet flagged as moving in the > > upward direction, and if that packet records that the transmitter is of > > a lower (lesser) Rank than the receiving node, then the receiving node > > is able to conclude that the packet has not progressed in the upward > > direction and that the DODAG is inconsistent. " > > > > > > ### Doing such checks in hardware forwarding paths isn’t exactly > > trivial. Is the assumption here that the packet forwarding rate is low, > > and hence software forwarding path is good enough? > > In general, today, it is the case that most LLN technologies are limited > more so by communication bandwidth than by processing bandwidth, i.e. > that > software in general can easily keep up with the link layer. But we do > not > intend to assume this in the design of RPL, and that RPL should be > applicable for other future technologies. > > More specifically, it is known in the art and practice that > 'forwarding-time' inconsistency detection is a useful technique for LLNs. > Such a detection technique does require this type of checking to be > done by > the receiving node. (Note that in our response to GenART comments we do > intend to add a few more informative references to give additional > background > to this rationale) > > We would then expect that any future LLN implementation that did > include HW > for the forwarding logic would have to accommodate this non-trivial > check. > > > > > > > > > Section 3.6.2: > > "DAGRank(M) equals DAGRank(N): In this case the positions of M and N > > within the DODAG and with respect to the DODAG root are similar > > (identical). Routing through a node with equal Rank may cause a routing > > loop (i.e., if that node chooses to route through a node with equal > Rank > > as well). > > > > ### Does this mean, one can’t route “upwards” via another node of the > > same rank? Wouldn’t think cause black holes in some scenarios where > that > > might be the only viable path left? > > That is true. This concept was denoted 'sibling' forwarding in the WG > (note the broad interpretation of 'sibling' as 'nodes of the same Rank' > does not necessarily imply common parents), and was explicitly ruled out > by the WG in favor of a more simplified/streamlined base specification > (Ticket 43). It is expected that this concept will be > elaborated/explored > further in future work. > > > > > > > Section 3.8.1.1: > > > > > > ### Nice example of nodes B and C both trying to get 2 parents. But > I am > > not sure, if the spec is crisp in terms of what are the rules to > avoid it. > > In this example it is our attempt to give a general illustration of how > greedy behavior can lead to loops/instabilities. At the end of the > example we do attempt to summarize the mechanisms RPL takes as follows: > > o This cycle can be averted through mechanisms in RPL: > > * Nodes (B) and (C) stay at a rank sufficient to attach to > their > most preferred parent (A) and don't go for any deeper > (worse) > alternate parents (Nodes are not greedy) > > * Nodes (B) and (C) do not process DIO messages from nodes > deeper than themselves (because such nodes are possibly in > their own sub-DODAGs) > > We could further clarify by adding a reference from this example to the > rules in Section 8.2.2.4, which serve to bound the impact greedy behavior > while allowing limited movement for local repair: > > 8.2.2.4. Rank and Movement within a DODAG Version > > ... > > 2. A node MAY advertise a Rank lower than its prior advertisement > within the DODAG Version. > > 3. Let L be the lowest rank within a DODAG Version that a given > node has advertised. Within the same DODAG Version, that node > MUST NOT advertise an effective rank higher than L + > DAGMaxRankIncrease. INFINITE_RANK is an exception to this > rule: > a node MAY advertise an INFINITE_RANK within a DODAG version > without restriction. If a node's Rank were to be higher than > allowed by L + DAGMaxRankIncrease, when it advertises Rank it > MUST advertise its Rank as INFINITE_RANK. > > ... > > Conceptually, an implementation is maintaining a DODAG parent set > within the DODAG Version. Movement entails changes to the DODAG > parent set. Moving Up does not present the risk to create a loop > but moving Down might, so that operation is subject to additional > constraints. > > ... > > A node is allowed to join any DODAG Version that it has never > been a > prior member of without any restrictions, but if the node has > been a > prior member of the DODAG Version then it must continue to observe > the rule that it may not advertise an effective rank higher than > L+DAGMaxRankIncrease at any point in the life of the DODAG > Version. > This rule must be observed so as not to create a loophole that > would > allow the node to effectively increment its rank all the way to > INFINITE_RANK, which may have impact on other nodes and create a > resource-wasting count-to-infinity scenario. > > > > > > > > Section 3.8.3: > > "This loop happens when a No-Path (a DAO message that invalidates a > > previously announced prefix) was missed and persists until all state > has > > been cleaned up." > > > > ### What is the trigger to cleanup old stale state? > > Generally this will be triggered by inconsistency detection as that > forwarding path is attempted and fails. This is covered in Section 11.2, > more specifically in Section 11.2.2.3: > > 11.2.2.3. DAO Inconsistency Loop Detection and Recovery > > A DAO inconsistency happens when a router has a downward route > that > was previously learned from a DAO message via a child, but that > downward route is not longer valid in the child, e.g. because that > related state in the child has been cleaned up. With DAO > inconsistency loop recovery, a packet can be used to recursively > explore and cleanup the obsolete DAO states along a sub-DODAG. > > In a general manner, a packet that goes Down should never go Up > again. If DAO inconsistency loop recovery is applied, then the > router SHOULD send the packet back to the parent that passed it > with > the Forwarding-Error 'F' bit set and the 'O' bit left untouched. > Otherwise the router MUST silently discard the packet. > > We can add a reference to Section 11.2 from Section 3.8.3 to help make > this > clear for the reader. > > > > > > > > > > > Section 3.8.3: > > RPL includes loop detection mechanisms that may mitigate the impact of > > DAO loops and trigger their repair. > > > > ### May? Shouldn’t this be a more stronger statement? Loops are bad ;) > > The problem with a stronger statement is that RPL does not guarantee loop > freedom. In practice strict loop avoidance is costly and difficult to > achieve in LLNs. RPL's approach tries to avoid the construction of > topologies that contain loops, further allows to detect a loop by the > detection of inconsistencies in a packet flow, and then to initiate a > repair. We could strike the 'may', since loop detection does certainly > mitigate the impact of DAO loops (even though that mitigation may not be > 100% effective). > > Prior to the text that you noted, in Section 3.8, we do say: > > 3.8. Loop Avoidance > > RPL avoids creating loops when undergoing topology changes and > includes rank-based datapath validation mechanisms for detecting > loops when they do occur (see Section 11 for more details). In > practice, this means that RPL guarantees neither loop free path > selection nor tight delay convergence times, but can detect and > repair a loop as soon as it is used. RPL uses this loop detection > to ensure that packets make forward progress within the DODAG > Version and trigger repairs when necessary. > > > > > > > > > There are a lot of usage of variable size values using TLV encoding. > The > > authors have chosen an 8 bit field for length. It ends up limiting to > > 256 bytes of payload. In many other protocols, this has become a > > “limitation” in the long run. Just wanted to bring to your > attention, if > > you see a need arising for bigger payloads. > > Noted. 8-bit length fields are thought to be sufficient for the majority > of the RPL options. In the case of the Metric Container, which may > exceed > 256 bytes, we did adopt the following convention in Section 6.7.4, which > could be carried forward to other options if needed: > > 6.7.4. Metric Container > > ... > > The Metric Container MAY appear more than once in the same RPL > control message, for example to accommodate a use case where the > Metric Data is longer than 256 bytes. More information is in > [I-D.ietf-roll-routing-metrics]. > > > > > > *Nits:* > > none > > > > Did we address your concerns? > > Regards, > -RPL Authors From Adrian.Farrel@huawei.com Mon Sep 20 23:13:44 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895693A691B; Mon, 20 Sep 2010 23:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.638 X-Spam-Level: X-Spam-Status: No, score=-100.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vveo5oOQGjms; Mon, 20 Sep 2010 23:13:43 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6B33C3A68DE; Mon, 20 Sep 2010 23:13:43 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9300EOY2NIWN@usaga01-in.huawei.com>; Mon, 20 Sep 2010 23:14:07 -0700 (PDT) Received: from your029b8cecfe (113-28-26-49.static.imsbiz.com [113.28.26.49]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9300HLV2NGKX@usaga01-in.huawei.com>; Mon, 20 Sep 2010 23:14:06 -0700 (PDT) Date: Tue, 21 Sep 2010 07:13:55 +0100 From: Adrian Farrel To: routing-discussion@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: Routing Area Directorate Subject: [RTG-DIR] draft-chroboczek-babel-routing-protocol-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 06:13:44 -0000 Hi, The IESG has received a request to consider the publication of this document as an RFC. I would like to solicit reviews of this document (ASAP :-) Thanks, Adrian ----- Original Message ----- From: To: Sent: Tuesday, July 27, 2010 5:30 PM Subject: I-D Action:draft-chroboczek-babel-routing-protocol-04.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : The Babel Routing Protocol > Author(s) : J. Chroboczek > Filename : draft-chroboczek-babel-routing-protocol-04.txt > Pages : 50 > Date : 2010-07-27 > > Babel is a loop-free distance vector routing protocol that is robust > and efficient both in ordinary wired networks and in wireless mesh > networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chroboczek-babel-routing-protocol-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From hadi@mojatatu.com Mon Sep 27 04:40:45 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13143A6D00 for ; Mon, 27 Sep 2010 04:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.531 X-Spam-Level: X-Spam-Status: No, score=-100.531 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNPhR58F7rth for ; Mon, 27 Sep 2010 04:40:43 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id A271B3A6A6B for ; Mon, 27 Sep 2010 04:38:34 -0700 (PDT) Received: by pvg7 with SMTP id 7so1576859pvg.31 for ; Mon, 27 Sep 2010 04:36:57 -0700 (PDT) Received: by 10.114.131.8 with SMTP id e8mr8275210wad.43.1285587416970; Mon, 27 Sep 2010 04:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.188.205 with HTTP; Mon, 27 Sep 2010 04:36:36 -0700 (PDT) From: Jamal Hadi Salim Date: Mon, 27 Sep 2010 07:36:36 -0400 Message-ID: To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: rtg-dir@ietf.org, draft-ietf-pce-manageability-requirements@tools.ietf.org Subject: [RTG-DIR] draft-ietf-pce-manageability-requirements-10 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 11:40:46 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pce-manageability-requirements-10 Reviewer: Jamal Hadi Salim Review Date: September 27, 2010 Intended Status: Historic Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: 1) Section 1, typo on last paragraph: s/authros/authors I suggest running the spell checker from the ietf tools 2) Section 1.2, FCAPS, page 3: I think it would make sense to have some reference to its definition. It may be hard (and i dont think Wikipedia can be used as a normative reference). 3) Section 1.2, bullets expanding FCAPS, page 3: I think for the intended audience (PCE draft authors), mentioning what FCAPS stands for maybe sufficient; for people outside PCE it would make the doc more readable to have 1-2 sentence on each of those bullets. 4) Section 1.2, paragraph 4, page 3: Suggest changing "He should reflect" to "The author should reflect" to make things gender neutral. 5) Section 1.2, paragraph 1 on top of page 4, last sentence: I think you have some reference failure translation there ... "work in progress" seems to refer to some document which may have been work in progress at some point. 6) Section 2, general comment: Although this is a historical doc, and this may be a little late in the game to whine about this: I think it would have been useful to provide some annotated examples for each of the considerations and recommended subsections(section 3 of this doc). When i scanned RFC 5706 it made for an interesting read because they provided examples. Example for the "Null Manageability" this document provides an excellent example (in fact mentioned at the end;->). I did scan RFC 5540 and it has excellent fitting examples.... 7) Section 2.3, last sentence: "In time, if an optional subsection is found to be common across many Internet-Drafts, it may be added to the list in Section 2.2 in a future revision of this document." Given this is a historic document - to be archived - is it ever going to be updated? If not, i suggest removing this piece... 8) Section 3.1, general: I think somewhere in there (not sure where in the flow), it would be useful to mention that not just the various parameters should be listed but also their default values. cheers, jamal From Adrian.Farrel@huawei.com Mon Sep 27 09:34:49 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4743A6B4E for ; Mon, 27 Sep 2010 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[AWL=-1.139, BAYES_50=0.001, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPdITy6BAMQ6 for ; Mon, 27 Sep 2010 09:34:44 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id E17E63A6BB7 for ; Mon, 27 Sep 2010 09:34:43 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9E00NVWZEY48@usaga01-in.huawei.com> for rtg-dir@ietf.org; Mon, 27 Sep 2010 09:35:22 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9E00787ZEW62@usaga01-in.huawei.com> for rtg-dir@ietf.org; Mon, 27 Sep 2010 09:35:22 -0700 (PDT) Date: Mon, 27 Sep 2010 17:35:15 +0100 From: Adrian Farrel To: Jamal Hadi Salim , rtg-ads@tools.ietf.org Message-id: <64782DF2754E459ABE4DCF1F2BC0B087@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: rtg-dir@ietf.org, draft-ietf-pce-manageability-requirements@tools.ietf.org Subject: Re: [RTG-DIR] draft-ietf-pce-manageability-requirements-10 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 16:34:49 -0000 Hi Jamal, Thanks for the review. It is a bit odd updating a Historic document! In a couple of cases below, I think your comments are right, but I propose to not make the updates because we ran the experiment with the (broken :-) draft. I'll let the AD comment if he disagrees with this disposition. > Comments: > > 1) Section 1, typo on last paragraph: > s/authros/authors > I suggest running the spell checker from the ietf tools Yes. Done. > 2) Section 1.2, FCAPS, page 3: > I think it would make sense to have some reference to its > definition. It may be hard (and i dont think Wikipedia can be used > as a normative reference). X.700 added. > 3) Section 1.2, bullets expanding FCAPS, page 3: > I think for the intended audience (PCE draft authors), mentioning > what FCAPS stands for maybe sufficient; for people outside PCE > it would make the doc more readable to have 1-2 sentence on each of > those bullets. I think the X.700 reference is enough. The work was run through PCE with these definitions, so I guess the result depended on how the PCE WG interpretted these minimal definitions. > 4) Section 1.2, paragraph 4, page 3: > Suggest changing "He should reflect" to "The author should reflect" > to make things gender neutral. Yes. > 5) Section 1.2, paragraph 1 on top of page 4, last sentence: > I think you have some reference failure translation there ... > "work in progress" seems to refer to some document which may > have been work in progress at some point. Thanks. Should have been a reference to RFC 5706. > 6) Section 2, general comment: > Although this is a historical doc, and this may be a little late in > the game to whine about this: I think it would have been useful > to provide some annotated examples for each of the considerations > and recommended subsections(section 3 of this doc). > When i scanned RFC 5706 it made for an interesting read because they > provided examples. Example for the "Null Manageability" this document > provides an excellent example (in fact mentioned at the end;->). > I did scan RFC 5540 and it has excellent fitting examples.... I have added a note at the top of section 2 to point out the examples listed in the Appendix. > 7) Section 2.3, last sentence: > "In time, if an optional subsection is found to be common across many > Internet-Drafts, it may be added to the list in Section 2.2 in a > future revision of this document." > > Given this is a historic document - to be archived - is it ever going > to be updated? If not, i suggest removing this piece... Fixed. > 8) Section 3.1, general: > I think somewhere in there (not sure where in the flow), it would > be useful to mention that not just the various parameters should > be listed but also their default values. I agree with this point and would make the change if we were still developing the document. But I think that the Historic RFC should record what was, not what should have been. New version will be posted soon. Cheers, Adrian From julien.meuric@orange-ftgroup.com Mon Sep 27 10:33:44 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A8A3A6D9F for ; Mon, 27 Sep 2010 10:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.742 X-Spam-Level: X-Spam-Status: No, score=-101.742 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxydQur4qiMi for ; Mon, 27 Sep 2010 10:33:43 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 697C63A6D73 for ; Mon, 27 Sep 2010 10:32:49 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9EE26FC400C for ; Mon, 27 Sep 2010 19:33:23 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 86CC5FC4002 for ; Mon, 27 Sep 2010 19:33:23 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Sep 2010 19:33:23 +0200 Received: from [10.193.71.158] ([10.193.71.158]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Sep 2010 19:33:21 +0200 Message-ID: <4CA0D562.2010901@orange-ftgroup.com> Date: Mon, 27 Sep 2010 19:33:22 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: rtg-dir@ietf.org References: <64782DF2754E459ABE4DCF1F2BC0B087@your029b8cecfe> In-Reply-To: <64782DF2754E459ABE4DCF1F2BC0B087@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Sep 2010 17:33:22.0062 (UTC) FILETIME=[14EA12E0:01CB5E6A] Subject: Re: [RTG-DIR] draft-ietf-pce-manageability-requirements-10 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 17:33:44 -0000 Hi. I'm not sure about the AD, but the one of the chairs agrees. Julien, helpful ;-) Le 27/09/2010 18:35, Adrian Farrel a écrit : > Hi Jamal, > > Thanks for the review. > > It is a bit odd updating a Historic document! > > In a couple of cases below, I think your comments are right, but I > propose to not make the updates because we ran the experiment with the > (broken :-) draft. I'll let the AD comment if he disagrees with this > disposition. > >> Comments: >> >> 1) Section 1, typo on last paragraph: >> s/authros/authors >> I suggest running the spell checker from the ietf tools > > Yes. Done. > >> 2) Section 1.2, FCAPS, page 3: >> I think it would make sense to have some reference to its >> definition. It may be hard (and i dont think Wikipedia can be used >> as a normative reference). > > X.700 added. > >> 3) Section 1.2, bullets expanding FCAPS, page 3: >> I think for the intended audience (PCE draft authors), mentioning >> what FCAPS stands for maybe sufficient; for people outside PCE >> it would make the doc more readable to have 1-2 sentence on each of >> those bullets. > > I think the X.700 reference is enough. The work was run through PCE > with these definitions, so I guess the result depended on how the PCE > WG interpretted these minimal definitions. > >> 4) Section 1.2, paragraph 4, page 3: >> Suggest changing "He should reflect" to "The author should reflect" >> to make things gender neutral. > > Yes. > >> 5) Section 1.2, paragraph 1 on top of page 4, last sentence: >> I think you have some reference failure translation there ... >> "work in progress" seems to refer to some document which may >> have been work in progress at some point. > > Thanks. Should have been a reference to RFC 5706. > >> 6) Section 2, general comment: >> Although this is a historical doc, and this may be a little late in >> the game to whine about this: I think it would have been useful >> to provide some annotated examples for each of the considerations >> and recommended subsections(section 3 of this doc). >> When i scanned RFC 5706 it made for an interesting read because they >> provided examples. Example for the "Null Manageability" this document >> provides an excellent example (in fact mentioned at the end;->). >> I did scan RFC 5540 and it has excellent fitting examples.... > > I have added a note at the top of section 2 to point out the examples > listed in the Appendix. > >> 7) Section 2.3, last sentence: >> "In time, if an optional subsection is found to be common across many >> Internet-Drafts, it may be added to the list in Section 2.2 in a >> future revision of this document." >> >> Given this is a historic document - to be archived - is it ever going >> to be updated? If not, i suggest removing this piece... > > Fixed. > >> 8) Section 3.1, general: >> I think somewhere in there (not sure where in the flow), it would >> be useful to mention that not just the various parameters should >> be listed but also their default values. > > I agree with this point and would make the change if we were still > developing the document. But I think that the Historic RFC should > record what was, not what should have been. > > New version will be posted soon. > > Cheers, > Adrian >