Re: [Roll] proposal for common table of contents for applicability statements

Abdussalam Baryun <abdussalambaryun@gmail.com> Fri, 06 July 2012 08:24 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCB521F85E4 for <roll@ietfa.amsl.com>; Fri, 6 Jul 2012 01:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.469
X-Spam-Level:
X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYvF-3cRD+7C for <roll@ietfa.amsl.com>; Fri, 6 Jul 2012 01:24:38 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 612C821F8630 for <roll@ietf.org>; Fri, 6 Jul 2012 01:24:38 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so6537702vbb.31 for <roll@ietf.org>; Fri, 06 Jul 2012 01:24:53 -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=mi5UeWJP5VQaa8VhPMjCVowkR6E73ycgN/R86+FuM/8=; b=PRBFEXI+b/43LEGK6n0NS0yiVNukJpcpclH+YKfBQXj4AanLMp5G5pnfAQbtjU6d2Q Egtd5xIxhiZC8osmuOmpGh0a+7GbYzvknuADkkpZt2bkCgdG6AALVzFvr1BmrOrLYwWN 3KcW/fS4O4OG2Blwsg5iyUD38S6MbKfzGGVgE25D+anjA8lysxGexqFo9lxqweeZnYcz jACgIPGdWDi7eeY1DKo4yuur/ELWUGG2wqSxoPLWc9agDs+8iaGu1cmwCyY33nCwykTV GSRFVOep1gmtJ2O28QgCVpKAf3hDc6B9UVusvXzqaXeJB90BDsyL4H6Zr23Qj3VMsnla +4gg==
MIME-Version: 1.0
Received: by 10.220.149.148 with SMTP id t20mr14086034vcv.12.1341563093795; Fri, 06 Jul 2012 01:24:53 -0700 (PDT)
Received: by 10.220.110.130 with HTTP; Fri, 6 Jul 2012 01:24:53 -0700 (PDT)
In-Reply-To: <CADnDZ883aso4+_2C=K=dpjqW+5nqXB0U2x7RP7nP5cqGFYkhWw@mail.gmail.com>
References: <CADnDZ883aso4+_2C=K=dpjqW+5nqXB0U2x7RP7nP5cqGFYkhWw@mail.gmail.com>
Date: Fri, 6 Jul 2012 10:24:53 +0200
Message-ID: <CADnDZ88rnMykqFLJxKPr0CbjPAcZ-betL5c1wmA-rR0EoXGbjA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: text/plain; charset=ISO-8859-1
Cc: roll <roll@ietf.org>
Subject: Re: [Roll] proposal for common table of contents for applicability statements
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Fri, 06 Jul 2012 08:24:39 -0000

+1

I will do my best to participate and review, thanking you,

Regards
AB

> Date: Thu, 05 Jul 2012 13:43:11 -0400
> From: Michael Richardson <mcr+ietf@sandelman.ca>;
> To: roll@ietf.org
> Subject: Re: [Roll] proposal for common table of contents for
>         applicability   statements
> Message-ID: <32407.1341510191@marajade.sandelman.ca>;
> Content-Type: text/plain; charset="us-ascii"
>
>
> Here is my proposal for a common table of contents for applicability
> statements.  I will turn this into an ID tomorrow.
>
> Proposed template table of contents for applicability statements.
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>      1.1.  Requirements Language  (RFC2119 reference)
>      1.2.  References/Overview of requirements documents, both
>            IETF and industry group.  (two pages maximum.  This text
>            should be (very) technical, should be aimed at IETF
> *participants*,
>            not industry group participants, and should explain this
>            industries' specific issues)
>      1.3   Out of scope requirements.
>            This should list other documents (if any) which deal with
>            situations where things are not in scope for this document.
>
>            (For instance, the AMI document tries to cover both line-powered
>            urban metering networks, and energy-constrained metering
> networks,
>            and also tries to deal with rural requirements.  This should
>            be three or four documents, so this section should list the
>            limits of what this document covers)
>
>    2.  Deployment Scenario
>      2.1.  Network Topologies
>        I would like to see a single scenario described, with possibly
>        multiple topologies that a single utility would employ.
>
>      2.2.  Traffic Characteristics  . . . . . . . . . . . . . . . . .  6
>        Explain what kind of traffic is being transmitted, where it is
>        initiated, and what kinds of protocols (CoAP, multicast, HTTPS,
> etc.)
>        are being used.  Explain what assumptions are being made about
>        authentication and authorization in those protocols.
>
>      for instance:
>      2.2.1.  General
>      2.2.2.  Source-sink (SS) communication paradigm
>      2.2.3.  Publish-subscribe (PS, or pub/sub) communication
>            paradigm
>      2.2.4.  Peer-to-peer (P2P) communication paradigm
>      2.2.5.  Peer-to-multipeer (P2MP) communication paradigm
>      2.2.6.  Additional considerations: Duocast and N-cast
>      2.2.7.  RPL applicability per communication paradigm
>
>
>      2.3 Layer 2 applicability.
>        Explain what layer-2 technologies this statement applies to, and
>        if there are options, they should be listed generally here, and
>        specifically in section 4.2.
>
>    3.  Using RPL to Meet Functional Requirements
>
>      This should explain in general terms how RPL is going to be used
>      in this network topology.  If trees that are multiple
>      layers deep are expected, then this should be described so that the
> fan
>      out is understood.
>      Some sample topologies (from simulations) should be explained, perhaps
>      with images references from other publications.
>
>      This section should tell an *implementer* in a lab, having a
> simulation
>      tool or a building/city/etc. to use as a testbed, how to construct
>      an LLN of sufficient complexity (but not too much) to validate an
>      implementation.
>
>    4.  RPL Profile
>      This section should list the various features of RPL plus other layers
>      of the LLN, and how they will be used.
>
>      4.1.  RPL Features
>        4.1.1.  RPL Instances
>        4.1.2.  Storing vs. Non-Storing Mode
>        4.1.3.  DAO Policy
>        4.1.4.  Path Metrics
>        4.1.5.  Objective Function
>        4.1.6.  DODAG Repair
>        4.1.7.  Multicast
>        4.1.8.  Security
>        4.1.9.  P2P communications
>
>      4.2.  Layer-two features
>        4.2.1.  Need layer-2 expert here.
>        4.2.2.  Security functions provided by layer-2.
>        4.2.3.  6LowPAN options assumed.
>        4.2.4.  MLE and other things
>
>       4.3.  Recommended Configuration Defaults and Ranges
>        4.3.1.  Trickle Parameters
>        4.3.2.  Other Parameters
>
>    5.  Manageability Considerations
>    6.  Security Considerations
>      6.1. Security Considerations during initial deployment.
>         (This section explains how nodes get their initial trust anchors,
>         initial network keys.  It explains if this happens at the factory,
>         in a deployment truck, if it is done in the field, perhaps
>         like
>
> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/CullenJennings.pdf)
>
>      6.2. Security Considerations during incremental deployment
>         (This section explains how that replaces a failed node takes
>         on the dead nodes' identity, or not.  How are nodes retired.
>         How are nodes removed if they are compromised)
>
>    7.  Other Related Protocols
>    8.  IANA Considerations
>    9.  Acknowledgements
>    10. References
>      10.1. Informative References
>      10.2. Normative References
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 307 bytes
> Desc: not available
> URL:
> <http://www.ietf.org/mail-archive/web/roll/attachments/20120705/81bc77ee/attachment.sig>
>
> ------------------------------
>