One document matched: draft-richardson-roll-applicability-template-02.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>

<rfc category="info" ipr="trust200902" docName="draft-richardson-roll-applicability-template-02">

<front>
  <title abbrev="roll-applicatbility">
      ROLL Applicability Statement Template 
  </title>

  <author initials="M." surname="Richardson" fullname="Michael C. Richardson">
    <organization abbrev="SSW">Sandelman Software Works</organization>
    <address>
      <postal>   
        <street>470 Dawson Avenue</street>
        <city>Ottawa</city>
        <region>ON</region>
        <code>K1Z 5V7</code>
        <country>CA</country>
      </postal>
      <email>mcr+ietf@sandelman.ca</email>
      <uri>http://www.sandelman.ca/</uri>
    </address>
  </author>

  <date month="February" year="2013" />

<abstract>
  <t>
    This document is a template applicability statement for the Routing over Low-power and Lossy Networks (ROLL) WG.
</t>
</abstract>

</front>

<middle>

<section title="Introduction">
<t>
This document is intended to remain as a Internet Draft.
</t>
<t>
The idea is that current and future Applicability statements will use the table of contents
provided.   The goal is that all applicability statements will have to cover the listed
items as a minimum.
</t>
  <section title="Requirements Language">
    <t>(RFC2119 reference)</t>
  </section>

  <section title="Required Reading">
    <t> 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)
    </t>
  </section>

  <section title="Out of scope requirements">
    <t> 
           This should list other documents (if any) which deal with
           situations where things are not in scope for this document.
    </t>
    <t>
           (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)
    </t>
  </section>
</section>

<section title="Deployment Scenario">
  <section title="Network Topologies">
    <t>
       describe a single scenario, with possibly
       multiple topologies that a single utility would employ.  
    </t>

  </section>
  <section title="Network Topologies">
    <section title="Traffic Characteristics">
    <t>
       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.
     </t>
     </section>

     <section title="General">
     </section>

     <section title="Source-sink (SS) communication paradigm ">
     </section>

     <section title="Publish-subscribe (PS, or pub/sub) communication paradigm ">
     </section>

     <section title="Peer-to-peer (P2P) communication paradigm  ">
     </section>

     <section title="Peer-to-multipeer (P2MP) communication paradigm ">
     </section>

     <section title="Additional considerations: Duocast and N-cast ">
     </section>

     <section title="RPL applicability per communication paradigm ">
     </section>
   </section>

   <section title="Layer 2 applicability.">
   <t>
       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.
   </t>
   </section>
</section>

<section title="Using RPL to Meet Functional Requirements  ">
<t>
     
     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.
</t>

<t>
     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.
</t>
</section>

<section title="RPL Profile  ">
<t>
     This section should list the various features of RPL plus other layers
     of the LLN, and how they will be used.
</t>

  <section title="RPL Features ">
    <section title="RPL Instances "></section>
    <section title="Storing vs. Non-Storing Mode"></section>
    <section title="DAO Policy "></section>
    <section title="Path Metrics "></section>
    <section title="Objective Function "></section>
    <section title="DODAG Repair "></section>
    <section title="Multicast  "></section>
    <section title="Security "></section>
    <section title="P2P communications "></section>
  </section>

  <section title="Layer-two features">
    <section title="Need layer-2 expert here."></section>
    <section title="Security functions provided by layer-2."></section>
    <section title="6LowPAN options assumed."></section>
    <section title="MLE and other things"></section>
  </section>

  <section title="Recommended Configuration Defaults and Ranges">
    <section title="Trickle Parameters "></section>
    <section title="Other Parameters "></section>
  </section>
</section>

<section title="Manageability Considerations">
</section>

<section title="Security Considerations  ">
  <section title="Security Considerations during initial deployment">
  <t>
        (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)
  </t>
  </section>
  <section title="Security Considerations during incremental deployment ">
  <t>
        (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)
  </t>
  </section>
</section>

<section title="Other Related Protocols"></section>
<section title="IANA Considerations"></section>
<section title="Acknowledgements"></section>
<section title="References">
  <section title="Informative References"></section>
  <section title="Normative References"></section>
</section>

</middle>

<back>
<references title="Normative references">
<?rfc include="reference.RFC.2119" ?>
</references>
</back>
</rfc>