Re: [secdir] secdir review of draft-ietf-roll-rpl-11

Tim Winter <> Tue, 14 September 2010 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE18D3A6991 for <>; Tue, 14 Sep 2010 08:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.955
X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uj-KyrNqtq5R for <>; Tue, 14 Sep 2010 08:57:11 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 421B13A681D for <>; Tue, 14 Sep 2010 08:57:11 -0700 (PDT)
Received: (qmail 29951 invoked from network); 14 Sep 2010 15:57:33 -0000
Received: from [] (wintert@ with plain) by with SMTP; 14 Sep 2010 08:57:33 -0700 PDT
X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk-
X-YMail-OSG: xLiJHCAVM1mCurJoPcO2SdUZnIgN_yy_m4f6qSGjrqu_Qjl m_cNBVoqeqs1QMUtl4TN7YTwbSVg2UnrfRMLkSdzROPZZy51yjBBvG0QFNCi fgeHfOZSMXF7RY4q22O5VMUIHzlv8iVZilebMjv1JvN77LrC0032w37bc2pE xYYYNhueXSO_XQDHpT4f5TBjEUX19gbCp2KvxGj6eKnWV3Aags5ctlYYlIXs DbqaMxU8TCk88rdu7L0hvlf6TD10EXhTt6wwOa.XguY0cYrpQ1YoNebDux8M ryt2Lmg4K4PgwyDa5Z0IAYRh4SWs-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Tue, 14 Sep 2010 11:57:30 -0400
From: Tim Winter <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100826 Thunderbird/3.0.7
MIME-Version: 1.0
To: Tina TSOU <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 14 Sep 2010 09:05:02 -0700
Subject: Re: [secdir] secdir review of draft-ietf-roll-rpl-11
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Sep 2010 15:57:13 -0000

Hi Tina,

On 08/31/2010 11:22 PM, Tina TSOU wrote:
 > I have reviewed this document as part of the security directorate's
 > ongoing effort to review all IETF documents being processed by the IESG.
 > These comments were written primarily for the benefit of the security
 > area directors. Document editors and WG chairs should treat these
 > comments just like any other last call comments.

Thank you for your review.

 > This draft is well written. I only have two comments.
 > 1. It is lack of manageability aspects to produce MIB;

As far as the MIB in general, we did not define a MIB but instead did
describe some general manageability aspects in Section 17.  We chose to
defer to the CoRE working group and other future work to specify the
details, as introduced in Section 17.1:

        Most of the existing IETF management standards are Structure of
        Management Information (SMI) based data models (MIB modules) to
        monitor and manage networking devices.

        For a number of protocols, the IETF community has used the IETF
        Standard Management Framework, including the Simple Network
        Management Protocol [RFC3410], the Structure of Management
        Information [RFC2578], and MIB data models for managing new

        As pointed out in [RFC5706], the common policy in terms of operation
        and management has been expanded to a policy that is more open to a
        set of tools and management protocols rather than strictly relying
        on a single protocol such as SNMP.

        In 2003, the Internet Architecture Board (IAB) held a workshop on
        Network Management [RFC3535] that discussed the strengths and
        weaknesses of some IETF network management protocols and compared
        them to operational needs, especially configuration.

        One issue discussed was the user-unfriendliness of the binary format
        of SNMP [RFC3410].  In the case of LLNs, it must be noted that at
        the time of writing, the CoRE Working Group is actively working on
        resource management of devices in LLNs.  Still, it is felt that this
        section provides important guidance on how RPL should be deployed,
        operated, and managed.

More specifically, we propose to add some text to call out aspects of
security manageability.

 > 2. Should be added flow examples for RPL;

We can come up with a few illustrative examples and add those to the draft.

 > B. R.  Tina

Does this address your concerns?


-RPL Authors