Re: [Anima] two EST question/suggestions

[Brian E Carpenter <[e-mail]>]

On 13/09/2017 08:51, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> wrote:
>     >> You need an MTI, and it should be the easiest and most compact thing to
>     >> implement.  While CoAP would be optimal, HTTP/1.1 is more than
>     >> sufficient, and the features in 2 in this case are not only unnecessary,
>     >> but undesirable overhead.
> 
>     > I am a bit bothered by the assumption that all devices of interest can be assumed
>     > to include X, for whatever value of X we deem to be MTI. Or are you only
>     > intending MTI to apply at the server end?
> 
> We are running over HTTP 1.1, we have to assume that.
> The issue is that both client and server libraries will grow HTTP 2, and we
> need to know if this is a problem.
> 
>     > It seems to me that we want to minimise the requirements for low end pledge
>     > devices, and every item that we make mandatory works against that.
> 
> BRSKI does not target constrained devices;  in the future having only an HTTP
> 2 library (because the application is using that) might be simplest.  Is it
> going to work okay?

I don't see why not. But isn't there potentially a class of devices that
while not being 'constrained' in the formal sense, nevertheless needs to
minimise its software footprint? So the implementer will want to choose
the solution with the smallest footprint, rather than whatever MTI we
happen to define in 2017.

Of course we can always change the MTI later, but if we say right now that
the MTI only applies to the server side, adding new solutions for future
types of pledge becomes more straightforward. As far as I can see, this
would have zero impact on first-generation implementations; initially
both servers and clients will support the MTI anyway.

   Brian