We could take the view that all nodes in a model being used by I2RS had
to have the potential to be ephemeral. While that would be attractive
for consistency, it puts a massive burden on the routing system
implemention. So we agreed that ephemeral marking was on a per-node
basis. Yes, that means that the model designer has to look at the
usage. Unfortunate, but a tradeoff.
When it comes to securing the transfer, the situation is very different.
Most importantly, the cost for supporting sending whatever the client
requests over an unsecure transport is small. And trying to guess which
information will be needed by monitoring or telemetry seems like to end
up with "all". Yes, there is a security risk with saying that telemetry
information may be send unencrypted. But either wwe accept that or we
don't. Trying to do node based marking does not seem to help the
situation, and it creates operational restrictions and complications.
Yours,
joel
On 5/26/16 1:08 PM, Susan Hares wrote:
Joel:
The purpose of allowing a non-security transport was to report status or
telemetry information. This information may be in a specific model, or a
portion of a model. While nodes may be too small an area, can you suggest
alternate wording here?
Please look at Ephemeral-REQ-05 for context of the use of "object"
Sue
-----------
Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model
that nodes have the following properties: ephemeral, writable/not-
writable, status/configuration, and secure/non-secure transport. (If
you desire examples, please see [I-D.hares-i2rs-protocol-strawman]
for potential yang syntax).
Ephemeral-REQ-05: The ability to augment an object with appropriate
YANG structures that have the property of being ephemeral. An object
defined as Yang module, schema tree, a schema node, submodule or
components of a submodule (derived types, groupings, data node, RPCs,
actions, and notifications".
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Joel Halpern
Sent: Wednesday, May 25, 2016 11:17 PM
To: [email protected]
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node
transport security
While I agree with the overall requirement that I2RS support both secured
and unsecured communication, I find Ephemeral-REQ-06 rather odd. Trying to
have the module designer specify whether the usage of a node (get, set,
...?) must be via a secure or unsecure transport seems a very odd placement
of the control.
Why are we mandating this on a per-node level?
Thank you,
Joel
On 5/25/16 9:39 PM, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Interface to the Routing System of the
IETF.
Title : I2RS Ephemeral State Requirements
Authors : Jeff Haas
Susan Hares
Filename : draft-ietf-i2rs-ephemeral-state-07.txt
Pages : 14
Date : 2016-05-25
Abstract:
This document covers requests to the NETMOD and NETCONF Working
Groups for functionality to support the ephemeral state requirements
to implement the I2RS architecture.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07
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.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
