Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt

From: <[email-masked]>
Date: Tue, 3 Feb 2015 10:08:22 +0000

Barbara, Tim,
thank-you for the draft! here are a few comments, plus some follow-ups on the thread discussing Joan's comments.

<<   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.
[phil] I found the last sentence quite hard to parse. I think the para means that the protocol must fulfil the criteria, but it is not mandatory-to-implement.
I admit to preferring MTI. If not, the protocol must define what happens if (say) the controller has implemented and the MA hasn't. Perhaps this is simple to do, as we assume a managed environment where the measuremnt system has deployed the controller and MAs?

<<   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.
[phil] I think "cause a session to be established" is a bit ambiguous. If I remember our discusisons in Dublin, I think this is not referring to Bootstrapping. we assume that the MA is integrated into the measuremnt system. 
this requirement means that the Controller must be able to send an Instruction to the MA, and the MA must be able to inform the Controller about its Failure and Logging Information (and Capabilities) (without an explicit request from the Controller)

<TAC> I would think versioning is a requirement; extensibility is comparative.
[phil] I agree - a protocol must have versioning. 

<<   CP-MUST-3  The protocol session must be capable of being secured
              using certificates, as described in
              [I-D.ietf-lmap-framework].
[phil] The framework gives certificates as an example mechanism. I'd be happy for certificates to be a MUST.

<<   CP-DIFF-7   How widely used is the protocol and/or its protocol
               elements in mass market devices? (widely is better)
I agree with the sentiment of this criteria (and the similar RP-DIFF-6). It seems important that we either re-use a protocol that's widely used, or that we build on an underlying, widely used protocol in some simple fashion. We certainly don't want to invent something from scratch. There seem quite important assessment around what's being added to an existing protocol (or protocol elements) and whether they're widely used or about to be. 

<<   CP-DIFF-8   What mechanisms exist to ensure interoperability of MA
               and Controller implementations? (existence of something
               is better)
I think interoperability is critical. To me it is the key reason for specifying the protocol. 

> RP-DIFF-4 Personally, would like to see compression mandatory 
> depending on the amount of data.
<BHS>What do others think? I have no strong opinion.
<TAC> Again this is more of a requirement that would need to be placed on a protocol; like versioning. We aren't creating requirements for a protocol but for comparing and selecting protocols. So again if we are saying we will not select a protocol that doesn't provide a compression capability then it should be a requirement not a comparative criteria. I don't think compression elevates to that "status". It is important though.
[phil] I don't think compression of reports is mandatory. For example, there may be very simple MAs that don't do this. Not sure that current systems do compression. Also, if a measurement system wants to compress reports, surely it can just compress the content completely independently of the lmap protocol, eg just zip it. 
so in fact I wonder whether this requirement is needed.

thanks
phil

________________________________________
From: lmap [[email-masked]] On Behalf Of STARK, BARBARA H [[email-masked]]
Sent: 15 January 2015 14:57
To: [email-masked]
Subject: [lmap] FW: New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt

This is the draft that Tim Carey and I put together for LMAP protocol selection criteria. It is taken from the slides we presented on the December teleconference, with a few changes based on the discussion during that call.
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 8:46 AM
To: STARK, BARBARA H; STARK, BARBARA H
Subject: New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt

A new version of I-D, draft-starkcarey-lmap-protocol-criteria-00.txt
has been successfully submitted by Barbara Stark and posted to the IETF repository.

Name:           draft-starkcarey-lmap-protocol-criteria
Revision:       00
Title:          LMAP Protocol Selection Criteria
Document date:  2015-01-15
Group:          Individual Submission
Pages:          6
URL:            http://www.ietf.org/internet-drafts/draft-starkcarey-lmap-protocol-criteria-00.txt
Status:         https://datatracker.ietf.org/doc/draft-starkcarey-lmap-protocol-criteria/
Htmlized:       http://tools.ietf.org/html/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].

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 3 Feb 2015 14:33:44 +0000

Hi Phil,
Thanks. In-line.
Barbara

> [phil] I found the last sentence quite hard to parse. I think the para means
> that the protocol must fulfil the criteria, but it is not mandatory-to-
> implement.
> I admit to preferring MTI. If not, the protocol must define what happens if
> (say) the controller has implemented and the MA hasn't. Perhaps this is
> simple to do, as we assume a managed environment where the measuremnt
> system has deployed the controller and MAs?

<bhs> I would absolutely envision LMAP making these criteria mandatory to implement (MTI) in any protocol LMAP selects (if using protocol X for LMAP, then criterion is MTI). But I don't think it's necessary for non-LMAP implementations or usages of a protocol to meet the LMAP criteria. As long as the protocol says how to do it in the context of the protocol, I'm satisfied that LMAP can easily mandate it. If it is MTI in the protocol itself, that's fine, too. Then LMAP doesn't have to mandate it.

> [phil] I think "cause a session to be established" is a bit ambiguous. If I
> remember our discusisons in Dublin, I think this is not referring to
> Bootstrapping. we assume that the MA is integrated into the measuremnt
> system.
> this requirement means that the Controller must be able to send an
> Instruction to the MA, and the MA must be able to inform the Controller
> about its Failure and Logging Information (and Capabilities) (without an
> explicit request from the Controller)

<bhs> This is not referring to bootstrapping. If a Controller needs to send a new Instruction to an MA *now*, then there has to be some way for the Controller to initiate that. We don't want the Controller to have to wait until the next scheduled time the MA contacts the Controller, before this Instruction can be sent. Likewise, if the MA needs to send something to the Controller *now*, the MA needs to be able to initiate that. When I look at some SNMP implementations, there's no ability for the SNMP Client to initiate communication with the SNMP server ("hey, server, I need to talk to you *now*"). Some other protocols may rely completely on the managed endpoint always initiating communication, with no mechanism for the server to initiate anything. Such protocols would fail these criteria. As a more concrete example, TR-069 requires the HTTPS/TCP sessions to be initiated by the managed endpoint. This would meet the 2nd criterion, but does nothing for the first. TR-069 also has a management server message that allows the server to send a message of "initiate a session with your management server *now*". This message doesn't actually establish the session (i.e., the client doesn't reply directly to this message), but the client does try to initiate a session when it gets this message. Independent of whether a protocol is "pull" or "push", either endpoint has to be able to cause communications to start.
 
> [phil] I agree - a protocol must have versioning.

<bhs> OK. I'll move the versioning criteria to the mandatory set.
 
> happy for certificates to be a MUST.

<bhs> OK. I agree. And if we need to word this differently, I'm happy to do so. This came out of some of the discussion we had on the call where we were talking about what references to use that would describe what was being required here.
 
> I agree with the sentiment of this criteria (and the similar RP-DIFF-6). It
> seems important that we either re-use a protocol that's widely used, or that
> we build on an underlying, widely used protocol in some simple fashion. We
> certainly don't want to invent something from scratch. There seem quite
> important assessment around what's being added to an existing protocol (or
> protocol elements) and whether they're widely used or about to be.
> 
> <TAC> Again this is more of a requirement that would need to be placed on a
> protocol; like versioning. We aren't creating requirements for a protocol but
> for comparing and selecting protocols. So again if we are saying we will not
> select a protocol that doesn't provide a compression capability then it should
> be a requirement not a comparative criteria. I don't think compression
> elevates to that "status". It is important though.
> [phil] I don't think compression of reports is mandatory. For example, there
> may be very simple MAs that don't do this. Not sure that current systems do
> compression. Also, if a measurement system wants to compress reports,
> surely it can just compress the content completely independently of the
> lmap protocol, eg just zip it.

<bhs> I'm fine with not making it mandatory. But I definitely want it as a comparative criterion. How much weight it gets remains to be seen.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Feb 2015 15:43:52 +0100

On Tue, Feb 03, 2015 at 02:33:44PM +0000, STARK, BARBARA H wrote:
> 
> <bhs> This is not referring to bootstrapping. If a Controller needs to send a new Instruction to an MA *now*, then there has to be some way for the Controller to initiate that. We don't want the Controller to have to wait until the next scheduled time the MA contacts the Controller, before this Instruction can be sent. Likewise, if the MA needs to send something to the Controller *now*, the MA needs to be able to initiate that. When I look at some SNMP implementations, there's no ability for the SNMP Client to initiate communication with the SNMP server ("hey, server, I need to talk to you *now*").

SNMP had notifications from day one. And implementation of SNMP that
does not support notifications is broken. That said, the real issue
here are NATs. Yes, it would be great if both parties could initiate
communication at any point in time. But in reality, middleboxes may
prevent that from happening. So is this requirement to addressed
without middleboxes in the way or does address this requirement
requires a solution that works around middleboxes?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>