Re: [Roll] Questions on the RPL applicability statement

"Popa, Daniel" <Daniel.Popa@itron.com> Tue, 28 January 2014 15:57 UTC

Return-Path: <Daniel.Popa@itron.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB611A023D for <roll@ietfa.amsl.com>; Tue, 28 Jan 2014 07:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 rYgBkOBJKbBj for <roll@ietfa.amsl.com>; Tue, 28 Jan 2014 07:56:57 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 853771A0227 for <roll@ietf.org>; Tue, 28 Jan 2014 07:56:57 -0800 (PST)
Received: from BY2PR04MB807.namprd04.prod.outlook.com (10.141.224.149) by BN1PR04MB552.namprd04.prod.outlook.com (10.141.65.152) with Microsoft SMTP Server (TLS) id 15.0.859.15; Tue, 28 Jan 2014 15:56:53 +0000
Received: from BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) by BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) with mapi id 15.00.0859.020; Tue, 28 Jan 2014 15:56:52 +0000
From: "Popa, Daniel" <Daniel.Popa@itron.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "roll@ietf.org" <roll@ietf.org>
Thread-Topic: Questions on the RPL applicability statement
Thread-Index: Ac8QdsnmrNUmVHo9RCm3bx7++6R1qQAIyfqAACZMC6ACLigogACVVz7w
Date: Tue, 28 Jan 2014 15:56:51 +0000
Message-ID: <fa07b96506b04434808b0b65ee85140f@BY2PR04MB807.namprd04.prod.outlook.com>
References: <7f3cf88e9e064bb28831d8b273e3169c@CO1PR04MB553.namprd04.prod.outlook.com> <13255.1389643159@sandelman.ca> <74c0ab9f632047febba938fe624a94e2@BY2PR04MB807.namprd04.prod.outlook.com> <1530.1390667859@sandelman.ca>
In-Reply-To: <1530.1390667859@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [109.2.132.3]
x-forefront-prvs: 0105DAA385
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(24454002)(55784002)(52604005)(243025003)(189002)(199002)(79102001)(76482001)(54356001)(74662001)(31966008)(87936001)(74502001)(66066001)(80022001)(85852003)(47446002)(65816001)(2656002)(94316002)(15202345003)(56776001)(83072002)(87266001)(46102001)(54316002)(81542001)(53806001)(59766001)(51856001)(76576001)(69226001)(56816005)(15975445006)(81686001)(81816001)(74876001)(90146001)(76796001)(85306002)(76786001)(74366001)(80976001)(86362001)(4396001)(81342001)(33646001)(63696002)(74316001)(93516002)(92566001)(77982001)(19580395003)(50986001)(47976001)(47736001)(93136001)(49866001)(74706001)(83322001)(19580405001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB552; H:BY2PR04MB807.namprd04.prod.outlook.com; CLIP:109.2.132.3; FPR:; InfoNoRecordsMX:1; A:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: itron.com
Subject: Re: [Roll] Questions on the RPL applicability statement
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 15:57:00 -0000

Hi Michael, 

Thanks for clarifying our questions. 

The remaining question is related to Section 8 " Other Related Protocols" as per  " draft-ietf-roll-applicability-template-04": What is the intent of this section? 

http://tools.ietf.org/pdf/draft-ietf-roll-applicability-template-04.pdf

Regards,
Daniel



-----Message d'origine-----
De : mcr@sandelman.ca [mailto:mcr@sandelman.ca] De la part de Michael Richardson
Envoyé : samedi 25 janvier 2014 17:38
À : roll@ietf.org
Cc : Popa, Daniel; Gillmore, Matthew
Objet : Re: Questions on the RPL applicability statement


Popa, Daniel <Daniel.Popa@itron.com> wrote:
    > You're right. In our document the section numbers do not match the
    > section numbers from the template you proposed.

    > The questions we have are:

    > - What is the intent of the Section called "Other protocols"?

I'm not sure.  I don't have such a section.
There are two sections that say, "Other Parameters".

I've posted a -04 with some details of what I think belongs in the first of those sections. The diffs are below.

    > - In your template there are 2 (distinct) sections called "Layer 2
    > applicability" and "Description of the Layer 2 features",
    > respectively. We wondering if these two sections are not somehow
    > redundant; what is the intent of having these 2 (distinct) sections?

section 2.3, layer-2, details what layer-2 technologies are going to be used.
This is at the high-level.  So in your document, you would write:

     This applicability statement applies to deployments using
     IEEE 802.15.4g, 802.15.4e, and for PowerLine Communication (PLC) IEEE P1901.2.

whereas in the home-building document it says:

   This document applies to [IEEE802.15.4] and [G.9959] which are
   adapted to IPv6 by the adaption layers [RFC4944] and
   [I-D.brandt-6man-lowpanz].

   (and it goes on to explain how 6lowpan is applied to form a layer-3, which
   actually, I think should go in the other section)

In the section of layer-2 features, I would expect to learn the significant details about each of the layer-2s being used.... if you are using the layer-2 security features, how they are configured (no security, per-network keying, per-node pair keying,  bootstrapping of new nodes...) and what assumptions one might reasonably be able to make about layer-3
security from layer-2 features.   This section will go a long long long way
towards making the security review easier:  if you claim that layer-2 guarantees no strangers on the network, then a whole bunch of threats go away.

{I'm a bit upset at the security reviews that we have got... They have occured, actually, way too soon, and in the wrong direction.  Still, all questions are important to answer}

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works