Re: [i2rs] I2RS Requriements - secure transfer

[Jeffrey Haas <[e-mail]>]

Joel,

On Tue, May 31, 2016 at 04:17:50PM -0400, Joel M. Halpern wrote:
> The more I read the text about marking secure or insecure
> transports, the I wonder whether it is an I2RS requirement at all.
> that is, I2RS requires the ability to send notifications via an
> insecure channel.

The requirements have been getting written in a very proscriptive manner for
the cases when security *is* required.  

We have had numerous discussions about other transports, which *might not*
be secured.

If your argument is that because we MUST support the secured cases that we
don't need to cover the insecure cases, I strongly disagree.

> I don't think I2RS cares what granularity this is marked at.

I2RS doesn't give a darn.  Models and security folk reviewing the models do.

> So lets not state a requirement on it?

Let's not try to brush it off.

> Jeff, you allude to using a protocol like IPFIX.  Given that IPFix
> won't be reading these YANG models at all, it seems that the
> requirement as stated (marking in the YANG which nodes are allowed
> to be transferred insecurely) won't help solve the problem.

Please try to have paid attention to the discussion the last two years about
pub-sub mechanisms for telemtry data.  We have more than one vendor which
has implemented some form of telemetry state coverable by yang modeling with
alternate presentation or transport layers.  The most common example
regularly cited has been GRPC with protobufs encoding. Discussion has
happened in-hallway, on-list and between vendors about the potential
programmatic mapping layers between things like protobufs, thrift and even
IPFIX and yang although to my knowledge only protobufs and thrift had gotten
more than a smattering of attention.

> I also wonder if the very notion of an I2RS protocol is getting in
> the way.  If the insecure transfer we envision is some protocol
> other than NetConf / RestConf, then we seem to be stating the
> requirement in the wrong place.

IMO, calling it an "I2RS protocol" was mistaken.  The minute we decided we
were going to attempt to leverage existing mechanisms such as netconf and
restconf, the framing should have simply been "extensions to support i2rs
cases".

If netconf proved intransigent against the changes in question, it was
likely at some point that the vendor set implementing i2rs mechanisms would
eventually chosen to have forked netconf protocol behaviors to support their
code and use cases for ephemeral state.  Thus far, it appears that each has
chosen to stay with their own internal forms of ephemeral configuration and
avoid exposing netconf mappings until these issues have resolved.

-- Jeff