One document matched: draft-starkcarey-lmap-protocol-criteria-01.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.draft-ietf-lmap-framework-11 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lmap-framework-11.xml">]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-starkcarey-lmap-protocol-criteria-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic -->

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title>LMAP Protocol Selection Criteria</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

<author fullname="Barbara Stark" initials="B.H."
            surname="Stark">
      <organization>AT&T</organization>

      <address>
        <postal>
          <street>1057 Lenox Park Blvd NE</street>

          <!-- Reorder these if your country does things differently -->

          <city>Atlanta</city>

          <region>GA</region>

          <code>30319</code>

          <country>US</country>
        </postal>

        <phone>+1-404-499-6424</phone>

        <email>bs7652@att.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Timothy Carey" initials="T."
            surname="Carey">
      <organization>Alcatel-Lucent</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region>TX</region>

          <code></code>

          <country>US</country>
        </postal>

        <phone>+1-972-415-2065</phone>

        <email>timothy.carey@alcatel-lucent.com</email>

       </address>
    </author>

    <date month="March" year="2015" />

    <!-- Meta-data Declarations -->

    <area>Operations & Management</area>

    <workgroup>Large-Scale Measurement of Broadband Performance</workgroup>

      <keyword>LMAP</keyword>
      <keyword>protocol</keyword>
      <keyword>criteria</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
       <t>This draft identifies criteria to be used by the LMAP WG in evaluating and selecting Control and Reporting Protocols described by <xref target="I-D.ietf-lmap-framework"></xref> and identified as WG deliverables in the LMAP charter. It is not intended for use for any other purpose or by any other party. This draft will not be maintained after LMAP completes its selection of these protocols. The authors of this draft do not intend to ask for working group adoption or formal publication by IETF.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This draft identifies criteria to be used in evaluating and selecting Control and Reporting Protocols described by <xref target="I-D.ietf-lmap-framework"></xref>. Both mandatory and comparative criteria are identified for these protocols.</t>

    </section>

    <section title="Control Protocol Criteria">
    <section title="Mandatory Criteria" anchor="ctrl_must">
      <t>Following is a list of criteria that a Control Protocol is required to support. Protocols that do not support these criteria will not be considered appropriate for selection by LMAP WG as a Control Protocol. Although it is mandatory that the described mechanisms have been defined for a protocol (in order for the protocol to be considered by LMAP as a candidate Control Protocol), the mechanisms do not need to be mandatory to implement per the protocol specification.</t>

      <t><list style="format CP-MUST-%d">
	<t>There must be a mechanism that allows a Controller to cause a session to be established with a MA. Identify this mechanism and where it is defined.</t>
	<t>There must be a mechanism that allows a MA to cause a session to be established with a Controller. Identify this mechanism and where it is defined.</t>
	<t>The protocol session must be capable of being secured using secure credentials, as described in <xref target="I-D.ietf-lmap-framework"></xref>. The security mechanism must be useful for privacy protection, man-in-the-middle defense, and protection against replay. Identify this mechanism and where it is defined.</t>
	<t>The protocol must be versionable. Identify the process for extending the protocol.</t>
      </list></t>
    </section>

    <section title="Comparative Criteria" anchor="ctrl_compare">
      <t>Following is a list of criteria that can be used to differentiate among  Control Protocol candidates. For each criterion, it is also indicated what  is considered "better" for a candidate protocol to support.</t>

      <t><list style="format CP-DIFF-%d">
	<t>How many exchanges are required to send a complete instruction set? (less is better)</t>
	<t>How many exchanges are required to send a status update? (less is better)</t>
	<t>Is it possible to provide partial updates? (yes is better)</t>
	<t>Are there any special mechanisms (other than STUN/TURN/ICE or using port forwarding pinholes, PCP, UPnP IGD, etc.) for NAT/firewall traversal?  (if subsequent evaluation of such a mechanism suggests it is useful and usable, yes is better)</t>
	<t>How many bytes of overhead (rough estimate or brief description of the source of overhead is acceptable) are required to send a complete instruction set? (less is better)</t>
	<t>How many bytes of overhead (rough estimate or brief description of the source of overhead is acceptable) are required to send a status update? (less is better)</t>
	<t>How widely used is the protocol and/or its protocol elements in mass market devices? (widely is better)</t>
	<t>What mechanisms exist to ensure interoperability of MA and Controller implementations (e.g., test tools, plugfests, certification programs, test plan or scripts, reference implementations to test against)? (existence of something is better)</t>
	<t>Are the components of the protocol available as open source? (yes is better)</t>
	<t>What ecosystem of tools exists for developers implementing the protocol (e.g., compilers, tutorials, sample and open source implementations; include tools for data model creation)? (existence of useful tools is better)</t>
	<t>Is the protocol versionable? (yes is better, or is this mandatory?)</t>
	<t>If yes, what is the process for extending the protocol? (for information)</t>
	<t>What are the encodings supported by the protocol (SOAP, JSON, XML, etc.)? (simple is better; lower overhead is better; other aspects still to be determined and discussed may be better)</t>
      </list></t>
    </section>

  </section> 

    <section title="Report Protocol Criteria">
    <section title="Mandatory Criteria" anchor="report_must">
      <t>Following is a list of criteria that a Report Protocol is required to support. Protocols that do not support these criteria will not be considered  appropriate for selection by LMAP WG as a Report Protocol. Although it is mandatory that the described mechanisms have been defined for a protocol (in order for the protocol to be considered by LMAP as a candidate Report Protocol), the mechanisms do not need to be mandatory to implement per the protocol specification.</t>

      <t><list style="format RP-MUST-%d">
	<t>There must be a mechanism that allows a MA to cause a session to be established with a Collector. Identify this mechanism and where it is defined.</t>
	<t>The protocol session must be capable of being secured using secure credentials, as described in <xref target="I-D.ietf-lmap-framework"></xref>. The security mechanism must be useful for privacy protection, man-in-the-middle defense, and protection against replay. Identify this mechanism and where it is defined.</t>
	<t>The protocol must be versionable. Identify the process for extending the protocol.</t>
      </list></t>
    </section>

    <section title="Comparative Criteria" anchor="report_compare">
      <t>Following is a list of criteria that can be used to differentiate among  Report Protocol candidates. For each criterion, it is also indicated what is  considered "better" for a candidate protocol to support.</t>

     <t><list style="format RP-DIFF-%d">
	<t>What transport protocols (TCP, UDP, other) can be used with the protocol? (WG to decide what is better)</t>
	<t>Is a congestion control mechanism supported? (yes is better)</t>
	<t>How many exchanges are required to send a report? (less is better)</t>
	<t>Does it allow for sending multiple reports in a session? (yes is better)</t>
	<t>Is there a capability for long-lived sessions. (yes is better)</t>
	<t>Is compression supported? (yes is better, or is this mandatory?)</t>
	<t>How many bytes of overhead (rough estimate or brief description of the source of overhead is acceptable) are required to send a report? (less is better)</t>
	<t>How widely used is the protocol and/or its protocol elements in mass market devices? (widely is better)</t>
	<t>What mechanisms exist to ensure interoperability of MA and Collector implementations (e.g., test tools, plugfests, certification programs, test plan or scripts, reference implementations to test against)? (existence of something is better)</t>
	<t>Are the components of the protocol available as open source? (yes is better)</t>
	<t>What ecosystem of tools exists for developers implementing the protocol (e.g., compilers, tutorials, sample and open source implementations; include tools for data model creation)? (existence of useful tools is  better)</t>
	<t>What are the encodings supported by the protocol (SOAP, JSON, XML, etc.)? (simple is better; lower overhead is better; other aspects still to be determined and discussed may be better)</t>
      </list></t>
    </section>

  </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Members of LMAP WG, including Dan Romascanu, Joan Luciani, Phil Eardley, and Juergen Schoenwaelder.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Candidate Control and Report protocols are required to meet security requirements identified in <xref target="I-D.ietf-lmap-framework"></xref>.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Normative References">

      &I-D.draft-ietf-lmap-framework-11;

    </references>

  </back>
</rfc>