Subject: [lmap] control protocol selection process

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 17:39:21 +0100

Hi,

I am wondering whether we over-engineer the control protocol selection
process. So far, there are four proposals on the table and the number
did not change for a year or so I think. Lets summarize the main
differences:

- All proposals support to run the protocol exchanges over HTTP. Two
  proposals in principle also allow the usage of NETCONF.

- Two proposals are YANG data model driven, two proposals come with a
  handmade resource and object model.

- The proposals differ in the approach used to establish connections
  and whether the interactions are more push or pull.

- The proposals may (or may) not differ in the data encoding used,
  e.g., XML or JSON.

Did I forget any other major difference?

If I now look at draft-starkcarey-lmap-protocol-criteria-00, then I
have the feeling that we are over-engineering the protocol selection
process. Do we really have to define precisely how to measure say "the
overhead to send a complete instruction set" given that the protocols
on the table are so close to each other? Would it perhaps be faster to
simply try to look at the differences mentioned above and to decide
what the WG prefers?

I am not criticizing draft-starkcarey-lmap-protocol-criteria-00 - I
think it is actually a very good document to have if there would be
substantially different proposals on the table. But frankly, I have
not yet heard about any proposals that I feel require this level of
detail, given that all protocols are some form of REST over HTTP.

/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/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 12 Feb 2015 16:42:27 +0000

Hi Juergen,

Please feel free to comment this during the virtual interim. 

It's basically about dropping some of the criteria. There are not that many. 

Regards,

Dan

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Thursday, February 12, 2015 6:39 PM
> To: [email-masked]
> Subject: [lmap] control protocol selection process
> 
> Hi,
> 
> process. So far, there are four proposals on the table and the number did not
> change for a year or so I think. Lets summarize the main
> differences:
> 
> If I now look at draft-starkcarey-lmap-protocol-criteria-00, then I have the
> feeling that we are over-engineering the protocol selection process. Do we
> really have to define precisely how to measure say "the overhead to send a
> complete instruction set" given that the protocols on the table are so close to
> each other? Would it perhaps be faster to simply try to look at the
> differences mentioned above and to decide what the WG prefers?
> 
> I am not criticizing draft-starkcarey-lmap-protocol-criteria-00 - I think it is
> actually a very good document to have if there would be substantially
> different proposals on the table. But frankly, I have not yet heard about any
> proposals that I feel require this level of detail, given that all protocols are
> some form of REST over HTTP.
> 
> /js
> 
> --
> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=SEk8pyiqvSnQW6dMCsAA9wTr8c
> xDG4S6zpZR8sYjNXU&s=62sIo2ay_XfXZYShOnB6a1WoDwtOdk1WZMHvhDx0
> __w&e= >
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_lmap&d=AwICAg&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=SEk8pyi
> qvSnQW6dMCsAA9wTr8cxDG4S6zpZR8sYjNXU&s=4uDKIqWNqOkIbH06VKL
> W76wFk19JaWkjmaUSZYw1cw0&e=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 17:54:03 +0100

Well, my point is to look at the protocol differences instead of
spending energy to define criterias that allow us to calculate
overheads and such things if at the end all protocols on the table
send similarly structured JSON over HTTP. I am not scared by the
number of criterias but by the effort it will take to define them
tightly and then we find that the difference is only in the length of
the member names (and that might not even be counted as overhead).

If anything matters, than it is the granularity / flexibility of the
resource model but even here it is a judgement call whether a more
flexible model is better. (It is better when it comes to scalability
but not when it comes to complexity and implementation costs.) So at
the end, we produce data but still have to make judgement calls on
what I believe a rather small number of issues, given the
characteristics of the proposals we have.

/js

On Thu, Feb 12, 2015 at 04:42:27PM +0000, Romascanu, Dan (Dan) wrote:
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 12 Feb 2015 17:00:49 +0000

Well, we need some documenting of the process that was used for the selection of the protocols. We  do not plan to make it too long, maybe one more iteration of the I-D. The call now starts and we can talk.

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, February 12, 2015 6:54 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [lmap] control protocol selection process
> 
> Well, my point is to look at the protocol differences instead of spending
> energy to define criterias that allow us to calculate overheads and such things
> if at the end all protocols on the table send similarly structured JSON over
> HTTP. I am not scared by the number of criterias but by the effort it will take
> to define them tightly and then we find that the difference is only in the
> length of the member names (and that might not even be counted as
> overhead).
> 
> If anything matters, than it is the granularity / flexibility of the resource
> model but even here it is a judgement call whether a more flexible model is
> better. (It is better when it comes to scalability but not when it comes to
> complexity and implementation costs.) So at the end, we produce data but
> still have to make judgement calls on what I believe a rather small number of
> issues, given the characteristics of the proposals we have.
> 
> /js
> 
> > > I am wondering whether we over-engineer the control protocol
> > > selection process. So far, there are four proposals on the table and
> > > the number did not change for a year or so I think. Lets summarize
> > > the main
> > > differences:
> > >
> > > process. Do we really have to define precisely how to measure say
> > > "the overhead to send a complete instruction set" given that the
> > > protocols on the table are so close to each other? Would it perhaps
> > > be faster to simply try to look at the differences mentioned above and to
> decide what the WG prefers?
> > >
> 3A__www.ietf.org_mail
> man_listinfo_lmap&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
> OcNXCJf
> > QzvlsiLQfucBXRucPvdrphpBsFA&m=cQyLlMGTmIuBRoc33cPzGG-
> zjmPToTi2ni5_dMVA
> > Q_Q&s=-tGE5J_fupa3HRzpKAt_G5JUPIt5uT1cDXBo2J5Ig4c&e=
> 
> --
> 2Duniversity.de_&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=cQyLlMGTmIuBRoc33cPzGG-
> zjmPToTi2ni5_dMVAQ_Q&s=pEA9P1BdqP2S7tPTsEMa7i9_pky7Jr3DIu5V0AB
> onMU&e= >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 18:04:36 +0100

Hi,

I do not think the IETF requires that every protocol selection needs a
formal approach like the one we are heading to. The chairs could
simply narrow the search space. You could say:

  The chairs believe the WG has consensus that the control protocol
  will allow to run over HTTP.

If nobody opposes this, we made a step forward by narrowing the search
space.

/js

---

From: <[email-masked]>
Date: Thu, 12 Feb 2015 17:49:45 +0000

I agree that this sort of narrowing would be a good idea (and that the -protocol-criteria draft is probably not the right place to discover / record such agreements)

phil

________________________________________
From: lmap [[email-masked]] On Behalf Of Juergen Schoenwaelder [[email-masked]]
Sent: 12 February 2015 17:04
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [lmap] control protocol selection process

Hi,

/js