Subject: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 04 May 2016 11:48:56 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-i2rs-pub-sub-requirements-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a couple of points I would like to discuss. Hopefully they can be
resolved easily:

Are there really no requirements for privacy or integrity protection? Is
there an expectation that this mechanism would ever carry privacy
sensitive or otherwise sensitive information?

- 4.2.5, 2nd to last paragraph:
I am surprised to find that, when the receiver is not the subscriber,
that the receiver is expected to opt-out. It seems like some form of
opt-in or affirmative consent would be needed here.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- General: I support Stephen's DISCUSS

-2.2: What is the real scope of this work? Is it expected to supplant the
mentioned mechanisms?

- 2.3: "We need a new pub-sub
   technology"
The shepherd write up mentioned a goal to use existing technologies. Is
the point of this sentence to suggest that is not feasible?

- 4.1, 4th paragraph:
The MAY doesn't seem right--is this a statement of fact that the
subscriber may have to resubscribe, or a requirement of the form that the
service MAY force the subscriber to resubscribe? (Be careful with MAYs in
requirements language--they imply unexpected things. For example, several
requirements say a SUBSCRIBE MAY do something--do those imply that the
service MUST allow the subscriber to do it ?)

-- 4.2.2, third bullet: The previous section said dampening periods MUST
be supported.

- 4.2.1, third paragraph: This is a bit ambiguous. I think it means to
change the what subtrees the subscription applies to, but could be
interpreted to change the subtrees themselves.

- 4.2.6.4: Would a mechanism that allowed out-of-order delivery but gave
the subscriber a way to reconstruct the order fulfill this requirement?

Nits:
- The shepherd write up suggests this is standards track. The draft and
tracker both say informational. Please update the shepherd writ up.

-3, last paragraph: What's the difference between a "Push" and an
"Update"?

-4.1: A forward reference to the subscription QoS section would be
helpful.

-- Last paragraph, last sentence: Sentence doesn't parse.

- 4.2.8, third paragraph: I don't think that should be a 2119 MAY

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 4 May 2016 23:24:50 +0000

Hi Ben,

Thanks for the comment.   In-line....

> From: Ben Campbell, May 04, 2016 2:49 PM
> I have a couple of points I would like to discuss. Hopefully they can be resolved
> easily:
> 
> Are there really no requirements for privacy or integrity protection? Is there an
> expectation that this mechanism would ever carry privacy sensitive or otherwise
> sensitive information?

When the subscription is established dynamically via an existing transport session (which is expected to be the dominant case) we have the same expectations for Privacy and integrity as would be provided via a "GET" instead of a "PUSH" over the same transport.   We could have replicated all these requirements, but that was seen as unnecessary and likely less secure than adopting existing mechanisms.

When the Subscriber and Receiver are different, then the transport connection will have credentials passed as part of the establishment.  These credentials will be used as a Security Grooming Filter just like the above case so that pushed objects will be excluded from an Update Notification as per the permissions of the Receiver.   (I.e., this is identical behavior to the above.)    As several people have had questions about this, the new v07 will make this explicit in the Security section.

> I am surprised to find that, when the receiver is not the subscriber, that the
> receiver is expected to opt-out. It seems like some form of opt-in or affirmative
> consent would be needed here.

The question really was how heavy-weight should the mechanism be.  Transports been considering are all encrypted.  So there is already a level of trust between the peers.  And a target can always pull down the connection if there are issues. 

In addition, multicast transports are viable for some future cases.  We didn't want mechanisms which complicated this type of interaction, especially in a world where dumb IoT devices may be involved.

No.   It is just showing that many specialized Push mechanism exist.  This is not intended to supplant existing mechanisms, although perhaps it can help avoid future dedicated solutions.
 
> The shepherd write up mentioned a goal to use existing technologies. Is the
> point of this sentence to suggest that is not feasible?

Existing technologies cannot meet all the requirements specified.  There are technology drafts progressing in NETCONF which can.

> - 4.1, 4th paragraph:
> The MAY doesn't seem right--is this a statement of fact that the subscriber may
> have to resubscribe, or a requirement of the form that the service MAY force the
> subscriber to resubscribe? (Be careful with MAYs in requirements language--they
> imply unexpected things. For example, several requirements say a SUBSCRIBE
> MAY do something--do those imply that the service MUST allow the subscriber
> to do it ?)

Good point.   Reworded in v07.

> -- 4.2.2, third bullet: The previous section said dampening periods MUST be
> supported.

Yes, but dampening is never for periodic subscriptions.
 
> - 4.2.1, third paragraph: This is a bit ambiguous. I think it means to change the
> what subtrees the subscription applies to, but could be interpreted to change the
> subtrees themselves.

Fixed
 
> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but gave the
> subscriber a way to reconstruct the order fulfill this requirement?

Yes, the timestamp within an update.  But this requirement targets a specific object in a specific subscription.  So there should be no issues.
 
> Nits:
> - The shepherd write up suggests this is standards track. The draft and tracker
> both say informational. Please update the shepherd writ up.

Fixed
 
> -3, last paragraph: What's the difference between a "Push" and an "Update"?

Reworded
 
> -4.1: A forward reference to the subscription QoS section would be helpful.

Moved the requirement in question to 4.2.6.
 
> -- Last paragraph, last sentence: Sentence doesn't parse.

Fixed
 
> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY

Fixed
 
Thanks again for the review!
Eric

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 04 May 2016 23:12:02 -0500

Hi, thanks for the response. Comments in line, with sections removed 
that do not seem to need further discussion:

On 4 May 2016, at 18:24, Eric Voit (evoit) wrote:

> When the subscription is established dynamically via an existing 
> transport session (which is expected to be the dominant case) we have 
> the same expectations for Privacy and integrity as would be provided 
> via a "GET" instead of a "PUSH" over the same transport.   We could 
> have replicated all these requirements, but that was seen as 
> unnecessary and likely less secure than adopting existing mechanisms.

Where do those requirements live now? I recall this draft mentioning 
that support for multiple transports is required, but I don't recall 
seeing anything about the required transport properties. (It's entirely 
possible I missed it, or just forgot.)

>
> When the Subscriber and Receiver are different, then the transport 
> connection will have credentials passed as part of the establishment.  
> These credentials will be used as a Security Grooming Filter just like 
> the above case so that pushed objects will be excluded from an Update 
> Notification as per the permissions of the Receiver.   (I.e., this is 
> identical behavior to the above.)    As several people have had 
> questions about this, the new v07 will make this explicit in the 
> Security section.

That will likely resolve my concern, but there's not enough detail here 
to judge. I will watch for the update.

>> that the
> The question really was how heavy-weight should the mechanism be.  
> Transports been considering are all encrypted.  So there is already a 
> level of trust between the peers.  And a target can always pull down 
> the connection if there are issues.

I think you are talking about solution, not requirements. If the 
solution is already known, what is the purpose of publishing the 
requirements?

>
> In addition, multicast transports are viable for some future cases.  
> We didn't want mechanisms which complicated this type of interaction, 
> especially in a world where dumb IoT devices may be involved.

I think my response to this will depend on the details you mention are 
coming in 07.

[...]

> Yes, but dampening is never for periodic subscriptions.

The third bullet is about on-change updates, not periodic publication. 
4.2.1 says the service MUST support dampening for on-change updates.

[...]

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 May 2016 06:15:07 -0400

Eric, Ben and IESG members: 

The pub/sub requirements are part of a 5 part requirements.   May I quote
from the shepherd's report: 

---------------------

The requirements for the first version of I2RS are: 

1) model driven ephemeral state - that is data models that do not survive

    a software or hardware reboot.  

https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

2) a secure protocol - 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme
nts/

3) traceability - ability to record interactions between I2RS elements 

(Client, Agent, Routing system) 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

4) notification publication via subscription 

5) Protocol to pass Data for Analytics  

The first version of these requirements does not include a 

separate analytical protocol requirements as the simple use cases may

pass information via query/poll or the notifications. 

The I2RS protocol exists in an secure environment described by: 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/

-------------------------

Eric - Perhaps it would be good to point to:

.         draft-ietf-i2rs-protocol-security-requirements and 

.         draft-ietf-i2rs-security-environment-reqs/

Ben - Can you tell me how the shepherd report could have been clearer?  The
I2rs protocol security requirements require:  confidentiality, encryption,
secure transport, protection against replay attack, protection against DDoS
attack (if possible).  

Ben - On opting in, once the receive accepts a transport connection from the
I2RS server - how is this not an opt-in to receive data? What are you
looking for? 

Sue Hares 

(shepherd) 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, May 04, 2016 7:25 PM
To: Ben Campbell; The IESG
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] Ben Campbell's Discuss on
draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

Hi Ben,

> I have a couple of points I would like to discuss. Hopefully they can 

> be resolved

> Are there really no requirements for privacy or integrity protection? 

> Is there an expectation that this mechanism would ever carry privacy 

> sensitive or otherwise sensitive information?

[eric's comment: 

When the subscription is established dynamically via an existing transport
session (which is expected to be the dominant case) we have the same
expectations for Privacy and integrity as would be provided via a "GET"
instead of a "PUSH" over the same transport.   We could have replicated all
these requirements, but that was seen as unnecessary and likely less secure
than adopting existing mechanisms.

When the Subscriber and Receiver are different, then the transport
connection will have credentials passed as part of the establishment.  These
credentials will be used as a Security Grooming Filter just like the above
case so that pushed objects will be excluded from an Update Notification as
per the permissions of the Receiver.   (I.e., this is identical behavior to
the above.)    As several people have had questions about this, the new v07
will make this explicit in the Security section.

End of eric's comment]

Sue: The transport provides for privacy, integrity protection.   Most
configuration in network boxes would need privacy. 

The question really was how heavy-weight should the mechanism be.
Transports been considering are all encrypted.  So there is already a level
of trust between the peers.  And a target can always pull down the
connection if there are issues. 

In addition, multicast transports are viable for some future cases.  We
didn't want mechanisms which complicated this type of interaction,
especially in a world where dumb IoT devices may be involved.

Sue: If the receiver accepts a secure transport set-up from the server, can
you provide the reason why this is not an "opt-in" once it receives the
connection from the I2RS agent? 

> -2.2: What is the real scope of this work? Is it expected to supplant 

> the mentioned mechanisms?

No.   It is just showing that many specialized Push mechanism exist.  This
is not intended to supplant existing mechanisms, although perhaps it can
help avoid future dedicated solutions.

> The shepherd write up mentioned a goal to use existing technologies. 

> Is the point of this sentence to suggest that is not feasible?

Existing technologies cannot meet all the requirements specified.  There are
technology drafts progressing in NETCONF which can.

> subscriber may have to resubscribe, or a requirement of the form that 

> the service MAY force the subscriber to resubscribe? (Be careful with 

> MAYs in requirements language--they imply unexpected things. For 

> example, several requirements say a SUBSCRIBE MAY do something--do 

> those imply that the service MUST allow the subscriber to do it ?)

> -- 4.2.2, third bullet: The previous section said dampening periods 

> MUST be supported.

Fixed

> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but 

> gave the subscriber a way to reconstruct the order fulfill this
requirement?

Yes, the timestamp within an update.  But this requirement targets a
specific object in a specific subscription.  So there should be no issues.

> - The shepherd write up suggests this is standards track. The draft 

> and tracker both say informational. Please update the shepherd writ up.

Fixed

"Update"?

Reworded

helpful.

Fixed

Fixed

Eric

_______________________________________________

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 May 2016 13:18:52 +0000

Hi Ben

Thanks, more in-line...

> From: Ben Campbell, May 05, 2016 12:12 AM
> 
> Hi, thanks for the response. Comments in line, with sections removed that do
> not seem to need further discussion:
> 
> 
> >> Is there an

In Susan's email, she points out other I2RS documents with such requirements such as:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/

The authors do hope that these subscription requirements will be applicable beyond I2RS protocols.  Therefore decoupling from transport to the degree possible seemed wise.  Therefore we didn't list some of the many documents which talk about ways to lock down existing and potential transports over which subscription updates might be pushed.  These exist elsewhere.  Example documents which could have been linked include: 
- RFC5539: NETCONF over Transport Layer Security
- RFC6242: Using the NETCONF Protocol over Secure Shell
- others relating to Restconf, HTTP, IPFIX, etc.
 
So in summary, it seems duplicative to bind in transport security references here when these should be picked up when a transport protocol selection is made.  But we can include if directed by the IESG.

> to judge. I will watch for the update.

Update posted.

> solution is already known, what is the purpose of publishing the

One technology solution is being worked in the NETCONF WG, but this is in flux.   Other solutions which don't meet the majority of these requirements are being worked elsewhere (e.g., OC-Telemetry.yang).   There is value in listing the requirements in of themselves.
 
> I think my response to this will depend on the details you mention are

This gets back to the point above about trying to maximally decouple subscription establishment security (discussed in this document) with transport payload security (which we believe is best left to the transports themselves to reference).

> >> MUST be

Yes, but on-change itself is as SHOULD.  See the requirement:
   A Subscription Service SHOULD support the ability to subscribe to
   updates "on-change", i.e., whenever values of subscribed data objects
   change.
IF on-change is supported, then dampening is a MUST.

The requirement in question must be written in a way which handles implementations which don't support on-change.

Eric

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 05 May 2016 16:31:12 -0500

> from the shepherd's report:

I think my confusion lies in the fact that, while the shepherd's writeup 
styles this draft as part of the I2RS protocol requirements, the draft 
itself claims to describe requirements for a generally useful pub-sub 
interface to a yang datastore. It's not clear to me how and when the 
I2RS protocol security requirements apply to it. If the described 
interface is intended to be useful in contexts other than I2RS (and the 
draft explicitly sets that expectation in 2.2), it needs to talk more 
generally about security and privacy.

For example, it might make sense to say that certain security 
requirements apply in environments where the mechanism might carry 
privacy sensitive data, and then point to the i2rs requirements for when 
the mechanism is used in an I2RS context.

A different approach might be to more tightly constrain this to i2rs

> I2RS server - how is this not an opt-in to receive data? What are you

I guess that depends on the transport. The transport requirements say 
the mechanism has to work over multiple transports. The last paragraph 
in 4.2.4 says "In the case of connection-oriented transports..." which 
suggests that non-connection-oriented transports are possible.

Even with a connection-oriented transport, this may depend on how 
connection-management is handled, and whether the receiver might be 
receiving things it _wants_ to receive on the same transport.

> transport
> These
> level
> We

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 05 May 2016 16:58:09 -0500

Hi Eric, same here.

[...]

>>>> expectation that this mechanism would ever carry privacy sensitive 
>>>> or
>>>> otherwise
>>>> sensitive information?
>>>
> The authors do hope that these subscription requirements will be 
> applicable beyond I2RS protocols.  Therefore decoupling from transport 
> to the degree possible seemed wise.  Therefore we didn't list some of 
> the many documents which talk about ways to lock down existing and 
> potential transports over which subscription updates might be pushed.  
> These exist elsewhere.  Example documents which could have been linked 
> include:
> So in summary, it seems duplicative to bind in transport security 
> references here when these should be picked up when a transport 
> protocol selection is made.  But we can include if directed by the 
> IESG.

(See my comments to Susan.) My concern here is that there are a 
assumptions about the security properties of the environment that need 
to be explicit. You don't have to restate everything, but pointing to 
those documents would help.

But there's still a fundemental conflict between the idea that this 
mechanism should be useful beyond the i2rs context, and the assumption 
of i2rs security mechanisms.

>> to judge. I will watch for the update.

Thanks, I saw that shortly after I sent this, but have not yet had time 
to look at it. I will do so as soon as I can.

>>>> receiver is expected to opt-out. It seems like some form of opt-in 
>>>> or
>>>> affirmative
> One technology solution is being worked in the NETCONF WG, but this is 
> in flux.   Other solutions which don't meet the majority of these 
> requirements are being worked elsewhere (e.g., OC-Telemetry.yang).   
> There is value in listing the requirements in of themselves.

I accept that--but if that is the case, it doesn't seem wise for the 
requirements to assume something is not a problem because it's not a 
problem for a particular solution.

> This gets back to the point above about trying to maximally decouple 
> subscription establishment security (discussed in this document) with 
> transport payload security (which we believe is best left to the 
> transports themselves to reference).
>

Hmm. I infer from that that requirements about how Updates are carried 
(as opposed to when and to whom they are carried) are not in scope here? 
But that still ties back to whether this is expected to be a general 
mechanism, vs just an i2rs or netconf mechanism.

> The requirement in question must be written in a way which handles 
> implementations which don't support on-change.

Ah, there lies the confusion. I interpreted the "(if supported)" part to 
be about whether the dampening period was supported, not about whether 
on-change was supported.

I suggest something to the effect of:
OLD
   The dampening period, for on-change update policy (if supported)
NEW
    The on-change policy dampening period (if the on-change policy is 
supported).

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 6 May 2016 02:13:41 +0000

+ more...

> From: Ben Campbell, May 05, 2016 5:58 PM
> 
> Hi Eric, same here.
> 
> >>>> or otherwise sensitive information?
> >>>
> >>> transport session (which is expected to be the dominant case) we
> >>> have the same expectations for Privacy and integrity as would be
> >>> provided
> >> seeing anything about the required transport properties. (It's
> >> entirely possible I missed it, or just forgot.)
> >
> (See my comments to Susan.) My concern here is that there are a assumptions
> about the security properties of the environment that need to be explicit. You
> don't have to restate everything, but pointing to those documents would help.

I have just inserted the following text into the start of Section 4.2.4.: "It is possible for updates coming from a Subscription Service to be pushed over different types of transports.  Good deployment practices will bind the Subscription Service into secure, encrypted transport layer mechanisms.  For example if NETCONF is used then RFC5523 would be a valid option to secure the transported information."   Do this meet your intent?
 
> But there's still a fundemental conflict between the idea that this mechanism
> should be useful beyond the i2rs context, and the assumption of i2rs security
> mechanisms.

I see no conflict because I2RS security mechanisms apply to I2RS deployments.  Existing transport security mechanisms can be applied for other deployment types.  This hopefully is highlighted/supported via the text just proposed above.

>From day 1 we have been aggregating requirements from beyond the I2RS domain.   Discussion across ADs for Routing and Ops and with multiple WG chairs have pointed us to an aggregated requirements draft.     These requirements are useful for I2RS deployment cases.  These requirements are useful for other use cases as well.   This draft has been reviewed with NETCONF and NETMOD, and the NETCONF has draft-ietf-netconf-yang-push (not bound to I2RS protocols) based on these requirements. 
 
> problem for a particular solution.

In the NETCONF WG we are doing our very best to decouple the subscription establishment and maintenance technology draft from the underlying transport drafts.  This is being well received; independent drafts for NETCONF, RESTCONF/HTTP subscription transport are on a path to adoption.  Broadband Forum members attending IETF96 have suggested we consider IPFIX transport.  Others have suggested COAP transport.  Still others are thinking about how to integrate it into GPB/GRPC.  

By avoiding transport specifics, the Subscription Service becomes more widely applicable. 
 
> mechanism, vs just an i2rs or netconf mechanism.

Hopefully this is addressed above.

>     The on-change policy dampening period (if the on-change policy is supported).

Makes sense.  Updated per your suggestion in the '-08' working copy.

Eric

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 May 2016 02:06:24 -0400

Ben:

This is the first of the "re-use" management protocols.  The requirements
are set-up so that we can suggest additions to the NETCONF and RESTCONF for
this first of I2RS.  

The I2RS ephemeral work, pub/sub, traceability, and security are target at
the I2RS protocol definition with the I2RS use case.  However, since these
are general additions to NETCONF/RESTCONF, this work can be used elsewhere. 

I think the text you are highlighting has this larger context.   Now, one of
the really important things to chat with Alia and Benoit is how do we handle
the wider use case.   Do we mention the wider context?  

The WG thought mentioning it was important.   

Sue 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, May 05, 2016 5:31 PM
To: Susan Hares
Cc: Eric Voit; The IESG; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] Ben Campbell's Discuss on
draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

On 5 May 2016, at 5:15, Susan Hares wrote:

> I2rs protocol security requirements require:  confidentiality, 
> encryption, secure transport, protection against replay attack, 
> protection against DDoS attack (if possible).

I think my confusion lies in the fact that, while the shepherd's writeup
styles this draft as part of the I2RS protocol requirements, the draft
itself claims to describe requirements for a generally useful pub-sub
interface to a yang datastore. It's not clear to me how and when the I2RS
protocol security requirements apply to it. If the described interface is
intended to be useful in contexts other than I2RS (and the draft explicitly
sets that expectation in 2.2), it needs to talk more generally about
security and privacy.

For example, it might make sense to say that certain security requirements
apply in environments where the mechanism might carry privacy sensitive
data, and then point to the i2rs requirements for when the mechanism is used
in an I2RS context.

>
>
>
> Ben - On opting in, once the receive accepts a transport connection 
> from the I2RS server - how is this not an opt-in to receive data? What 
> are you looking for?

I guess that depends on the transport. The transport requirements say the
mechanism has to work over multiple transports. The last paragraph in 4.2.4
says "In the case of connection-oriented transports..." which suggests that
non-connection-oriented transports are possible.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 06 May 2016 14:38:05 -0500

Hi Susan,

To be clear, I do not object to the wider context per se. My concern is 
that the security and privacy requirements are left as implicit, based 
on the more narrow i2rs/netconf context. I only mentioned the potential 
of restricting the contextas one possible way forward; I am certainly 
not wedded to it.

My suggestion for a way forward would be to document the high level 
security and privacy requirements in this document. IIUC, the larger 
context includes potentially unknown contexts, so some of this may need 
to be conditional. For example, language like the following might be 
helpful (this is just an example--I don't mean to say that it is true or 
applicable):

  "Some uses of this mechanism may carry privacy-sensitive information, 
or generate    privacy-sensitive metadata through the subscription 
mechanism. In contexts where this is true, the following requirements 
apply..."

It might also be reasonable to say that, for the context of i2rs, these 
requirements are documented in [references] and are expected to be 
fulfilled by the [transport and or protocol]

Eric's email also suggested that the actual transport of data from the 
Yang datastore may be out of scope for these requirements. I don't 
object to that, either, as long as it is clear and explicit, although it 
would be good to point to where it is _in_ scope.

Thanks!

Ben.

On 6 May 2016, at 1:06, Susan Hares wrote:

>> Ben - Can you tell me how the shepherd report could have been 
>> clearer?
>>  The
> I2RS
> requirements
> the