LMAP Protocol Selection Criteria
draft-starkcarey-lmap-protocol-criteria-01

Abstract

This draft identifies criteria to be used by the LMAP WG in evaluating and selecting Control and Reporting Protocols described by [I-D.ietf-lmap-framework] 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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 2, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Control Protocol Criteria
• 2.1. Mandatory Criteria
• 2.2. Comparative Criteria
• 3. Report Protocol Criteria
• 3.1. Mandatory Criteria
• 3.2. Comparative Criteria
• 4. Acknowledgements
• 5. IANA Considerations
• 6. Security Considerations
• 7. Normative References
• Authors' Addresses

1. Introduction

This draft identifies criteria to be used in evaluating and selecting Control and Reporting Protocols described by [I-D.ietf-lmap-framework]. Both mandatory and comparative criteria are identified for these protocols.

2. Control Protocol Criteria

2.1. Mandatory Criteria

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.

CP-MUST-1

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.

CP-MUST-2

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.

CP-MUST-3

The protocol session must be capable of being secured using secure credentials, as described in [I-D.ietf-lmap-framework]. 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.

CP-MUST-4

The protocol must be versionable. Identify the process for extending the protocol.

2.2. Comparative Criteria

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.

CP-DIFF-1

How many exchanges are required to send a complete instruction set? (less is better)

CP-DIFF-2

How many exchanges are required to send a status update? (less is better)

CP-DIFF-3

Is it possible to provide partial updates? (yes is better)

CP-DIFF-4

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)

CP-DIFF-5

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)

CP-DIFF-6

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)

CP-DIFF-7

How widely used is the protocol and/or its protocol elements in mass market devices? (widely is better)

CP-DIFF-8

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)

CP-DIFF-9

Are the components of the protocol available as open source? (yes is better)

CP-DIFF-10

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)

CP-DIFF-11

Is the protocol versionable? (yes is better, or is this mandatory?)

CP-DIFF-12

If yes, what is the process for extending the protocol? (for information)

CP-DIFF-13

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)

3. Report Protocol Criteria

3.1. Mandatory Criteria

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.

RP-MUST-1

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.

RP-MUST-2

The protocol session must be capable of being secured using secure credentials, as described in [I-D.ietf-lmap-framework]. 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.

RP-MUST-3

The protocol must be versionable. Identify the process for extending the protocol.

3.2. Comparative Criteria

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.

RP-DIFF-1

What transport protocols (TCP, UDP, other) can be used with the protocol? (WG to decide what is better)

RP-DIFF-2

Is a congestion control mechanism supported? (yes is better)

RP-DIFF-3

How many exchanges are required to send a report? (less is better)

RP-DIFF-4

Does it allow for sending multiple reports in a session? (yes is better)

RP-DIFF-5

Is there a capability for long-lived sessions. (yes is better)

RP-DIFF-6

Is compression supported? (yes is better, or is this mandatory?)

RP-DIFF-7

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)

RP-DIFF-8

How widely used is the protocol and/or its protocol elements in mass market devices? (widely is better)

RP-DIFF-9

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)

RP-DIFF-10

Are the components of the protocol available as open source? (yes is better)

RP-DIFF-11

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)

RP-DIFF-12

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)

4. Acknowledgements

Members of LMAP WG, including Dan Romascanu, Joan Luciani, Phil Eardley, and Juergen Schoenwaelder.

5. IANA Considerations

This memo includes no request to IANA.

6. Security Considerations

Candidate Control and Report protocols are required to meet security requirements identified in [I-D.ietf-lmap-framework].

7. Normative References

Authors' Addresses