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

Abstract

This draft identifies criteria to be used in evaluating and selecting Control and Reporting Protocols described by [I-D.ietf-lmap-framework].

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 July 19, 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
• 1.1. Requirements Language
• 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.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

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 as a Control Protocol. Note that although the protocol may support the criterion, it is not necessarily the case that the criterion is mandatory to implement according to 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.

CP-MUST-2

There must be a mechanism that allows a MA to cause a session to be established with a Controller.

CP-MUST-3

The protocol session must be capable of being secured using certificates, as described in [I-D.ietf-lmap-framework].

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? (asked out of curiosity, but not expecting anything)

CP-DIFF-5

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

CP-DIFF-6

How many bytes of overhead 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? (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 (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.)? (for information)

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 as a Report Protocol. Note that although the protocol may support the criterion, it is not necessarily the case that the criterion is mandatory to implement according to 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.

RP-MUST-2

The protocol session must be capable of being secured using certificates, as described in [I-D.ietf-lmap-framework].

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

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

RP-DIFF-2

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

RP-DIFF-3

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

RP-DIFF-4

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

RP-DIFF-5

How many bytes of overhead are required to send a report? (less is better)

RP-DIFF-6

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

RP-DIFF-7

What mechanisms exist to ensure interoperability of MA and Collector implementations? (existence of something is better)

RP-DIFF-8

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

RP-DIFF-9

What ecosystem of tools exists for developers implementing the protocol (include tools for data model creation)? (existence of useful tools is better)

RP-DIFF-10

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

RP-DIFF-11

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

RP-DIFF-12

What are the encodings supported by the protocol (SOAP, JSON, XML, etc.)? (for information)

4. Acknowledgements

Members of LMAP WG.

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