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

From: Susan Hares <[email-masked]>
Date: Fri, 06 May 2016 18:09:13 -0500

Ben:
This is wise idea.  I will suggest some text to Eric and you in the morning.
Sue

Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone-------- Original message --------From: Ben Campbell <[email-masked]> Date: 5/6/2016  2:38 PM  (GMT-06:00) To: Susan Hares <[email-masked]> Cc: Eric Voit <[email-masked]>, The IESG <[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 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:
>
> 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:
>
>> 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-req
>> uireme
>> 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
>>
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/
>>
>>
>>
>> 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).
>
> 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
>
>>
>>
>>
>> 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.
>
> 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.
>
>>
>>
>>
>> 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,
>>
>>
>>
>> Thanks for the comment.   In-line....
>>
>>
>>
>>> From: Ben Campbell, May 04, 2016 2:49 PM
>>
>>> ----------------------------------------------------------------------
>>
>>> 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?
>>
>>
>>
>> [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.
>>
>>
>>
>>> - 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.
>>
>>
>>
>> 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?
>>
>>
>>
>>
>>
>>> ----------------------------------------------------------------------
>>
>>> 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?
>>
>>
>>
>> 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.
>>
>>> - 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?
>>
>>
>>
>> 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
>>
>> _______________________________________________
>>
>> 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: Fri, 13 May 2016 15:26:25 +0000

Hi Ben,

I have added the text below as the lead-in to section 4.2.5.  I believe this meets the intents of your suggestions below.

Hi Susan & Alia,

I have uploaded v08 of
https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/
If Ben concurs with the text below, I am not aware of any remaining discuss items.

Thanks everyone for your reviews,
Eric, Alex, & Alberto

4.2.5.  Security Requirements

   Some uses of this Subscription Service will push privacy-sensitive

   updates and metadata.  Good deployment practices will bind this

   generated information within secure, encrypted transport layer

   mechanisms.  For example if NETCONF is used as transport, then

   [RFC5539] would be a valid option to secure the transported

   information.  The Subscription Service can also be used with emerging

   deployment contexts as well.  As an example, deployments based on

   [i2rs-usecase] can apply these requirements in conjunction with those

   documented within [i2rs-protocol-security] to secure ephemeral state

   information being pushed from a Network Element.

From: Susan Hares [mailto:[email-masked]]
Sent: Friday, May 06, 2016 7:09 PM
To: Ben Campbell
Cc: Eric Voit (evoit); 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)

Ben:

Sue

Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
-------- Original message --------
From: Ben Campbell <[email-masked]<mailto:[email-masked]>>
Date: 5/6/2016 2:38 PM (GMT-06:00)
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: Eric Voit <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

Hi Susan,

Thanks!

Ben.

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

> Cc: Eric Voit; The IESG; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>  <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
>>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 13 May 2016 11:49:01 -0400

Eric: 

Thanks for jumping in and putting out text that resolves Ben’s comments.  This text works for me with one addition.  Add reference to the security environment draft. 

Sue 

From: Eric Voit (evoit) [mailto:[email-masked]] 
Sent: Friday, May 13, 2016 11:26 AM
To: Susan Hares; Ben Campbell; Alia Atlas ([email-masked])
Cc: 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)

Hi Ben,

Hi Susan & Alia,

I have uploaded v08 of

Eric, Alex, & Alberto

 

Ben:

Sue

-------- Original message --------

From: Ben Campbell <[email-masked]> 

To: Susan Hares <[email-masked]> 

Cc: Eric Voit <[email-masked]>, The IESG <[email-masked]>, [email-masked], [email-masked], [email-masked] 

Hi Susan,

Thanks!

Ben.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 13 May 2016 17:16:28 +0000

Sue,

Made your change  (see green below).   I will await everyone else’s ok to see if there are any final changes before posting.

Eric

   Some uses of this Subscription Service will push privacy-sensitive
   updates and metadata.  Good deployment practices will bind this
   generated information within secure, encrypted transport layer
   mechanisms.  For example if NETCONF is used as transport, then
   [RFC5539] would be a valid option to secure the transported
   information.  The Subscription Service can also be used with emerging
   deployment contexts as well.  As an example, deployments based on
   [i2rs-usecase] can apply these requirements in conjunction with those
   documented within [i2rs-environment-security]and
   [i2rs-protocol-security] to secure ephemeral state information being
   pushed from a Network Element.

From: Susan Hares, May 13, 2016 11:49 AM

Eric:

Sue

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Friday, May 13, 2016 11:26 AM
To: Susan Hares; Ben Campbell; Alia Atlas ([email-masked]<mailto:[email-masked]>)
Cc: The IESG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

Hi Ben,

Hi Susan & Alia,

I have uploaded v08 of

From: Susan Hares [mailto:[email-masked]]
Sent: Friday, May 06, 2016 7:09 PM
To: Ben Campbell
Cc: Eric Voit (evoit); The IESG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

Ben:

Sue

-------- Original message --------
From: Ben Campbell <[email-masked]<mailto:[email-masked]>>
Date: 5/6/2016 2:38 PM (GMT-06:00)
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: Eric Voit <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

Hi Susan,

Thanks!

Ben.

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 14 May 2016 12:57:35 -0400

Eric: 

Thank you for making the change. 

Sue 

From: Eric Voit (evoit) [mailto:[email-masked]] 
Sent: Friday, May 13, 2016 1:16 PM
To: Susan Hares; 'Ben Campbell'; 'Alia Atlas'
Cc: '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)

Sue,

Eric

 

Eric: 

Sue 

Hi Ben,

Hi Susan & Alia,

I have uploaded v08 of

Eric, Alex, & Alberto

 

Ben:

Sue

-------- Original message --------

Hi Susan,

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Sun, 15 May 2016 14:17:57 -0500

Hi Eric and Sue,

Thanks for the change, and I think it's on the right track. But I notice 
most of the other requirements, in the security considerations section 
and in other sections, use 2119 keywords. Is there a reason not to do so 
here? Would it be reasonable to say that any embodiment of these 
requirements MUST support a transport that provides encryption and 
integrity protection, and such a transport MUST be used when carrying 
privacy-sensitive information?

Thanks!

Ben.

On 13 May 2016, at 10:49, Susan Hares wrote:

> Eric:
>
>
>
> Thanks for jumping in and putting out text that resolves Ben’s 
> comments.  This text works for me with one addition.  Add reference to 
> the security environment draft.
>
>
>
> Sue
>
>
>
> Cc: The IESG; [email-masked]; 
> Subject: RE: [i2rs] Ben Campbell's Discuss on 
> I have added the text below as the lead-in to section 4.2.5.  I 
> believe this meets the intents of your suggestions below.
>
>
>
> Hi Susan & Alia,
>
>
>
> I have uploaded v08 of
>
> Cc: Eric Voit (evoit); The IESG; [email-masked]; 
> Cc: Eric Voit <[email-masked]>, The IESG <[email-masked]>, 
> [email-masked], [email-masked], 
> [email-masked]
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 16 May 2016 13:46:36 +0000

Hi Ben,

There is no issue with rewording to a requirement rather than an intro.  The second sentence below has been changed to meet 2119.

Some uses of this Subscription Service will push privacy-sensitive updates and metadata.  For privacy-sensitive deployments, subscription information MUST be bound within secure, encrypted transport layer mechanisms.  For example if NETCONF is used as transport, then [RFC5539] would be a valid option to secure the transported information.  The Subscription Service can also be used with emerging privacy-sensitive deployment contexts as well.  As an example, deployments based on [i2rs-usecase] would apply these requirements in conjunction with those documented within [i2rs-environment-security] and [i2rs-protocol-security] to secure ephemeral state information being pushed from a Network Element.

Eric

> From: Ben Campbell, May 15, 2016 3:18 PM

> Thanks for the change, and I think it's on the right track. But I notice most of the

> other requirements, in the security considerations section and in other sections,

> use 2119 keywords. Is there a reason not to do so here? Would it be reasonable

> to say that any embodiment of these requirements MUST support a transport

> that provides encryption and integrity protection, and such a transport MUST be

> used when carrying privacy-sensitive information?

> > Cc: The IESG; [email-masked]<mailto:[email-masked]>;

> > If Ben concurs with the text below, I am not aware of any remaining

> > discuss items.

> >    information.  The Subscription Service can also be used with

> > emerging

> >    [i2rs-usecase] can apply these requirements in conjunction with

> > those

> >    documented within [i2rs-protocol-security] to secure ephemeral

> > state

> > Cc: Eric Voit (evoit); The IESG; [email-masked]<mailto:[email-masked]>;

> > This is wise idea.  I will suggest some text to Eric and you in the

> > morning.

> > Cc: Eric Voit <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>,

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

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

> > To be clear, I do not object to the wider context per se. My concern

> > on the more narrow i2rs/netconf context. I only mentioned the

> > potential

> > context includes potentially unknown contexts, so some of this may

> > need

> > helpful (this is just an example--I don't mean to say that it is true

> > or

> >   "Some uses of this mechanism may carry privacy-sensitive

> > information,

> > It might also be reasonable to say that, for the context of i2rs,

> > object to that, either, as long as it is clear and explicit, although

> > it

> >>> separate analytical protocol requirements as the simple use cases

> >>> may

> >> styles this draft as part of the I2RS protocol requirements, the

> >> draft

> >> protocol security requirements apply to it. If the described

> >> interface

> >> says "In the case of connection-oriented transports..." which

> >> suggests

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

> >>>> privacy

> >>> connection will have credentials passed as part of the

> >>> establishment.

> >>> Sue: The transport provides for privacy, integrity protection.

> >>> Most

> >>>> that the receiver is expected to opt-out. It seems like some form

> >>>> of

> >>> Transports been considering are all encrypted.  So there is already

> >>> a

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

> >>>> technologies.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 16 May 2016 11:06:31 -0400

That works for me. I will clear the DISCUSS.

Thanks!

Ben.

On 16 May 2016, at 9:46, Eric Voit (evoit) wrote:

> Hi Ben,
>
>
>
> There is no issue with rewording to a requirement rather than an 
> intro.  The second sentence below has been changed to meet 2119.
>
>
>
> updates and metadata.  For privacy-sensitive deployments, subscription 
> information MUST be bound within secure, encrypted transport layer 
> privacy-sensitive deployment contexts as well.  As an example, 
> deployments based on [i2rs-usecase] would apply these requirements in 
> conjunction with those documented within [i2rs-environment-security] 
> and [i2rs-protocol-security] to secure ephemeral state information 
> being pushed from a Network Element.
>
>
>
> Eric
>
>
>
>>> To: Susan Hares; Ben Campbell; Alia Atlas 
>>> ([email-masked]<mailto:[email-masked]>)
>
>>> [email-masked]<mailto:[email-masked]>; 
>>> [email-masked]<mailto:[email-masked]>; 
>>> [email-masked]<mailto:[email-masked]>, 
>>> [email-masked]<mailto:[email-masked]>,
>
>>>> [email-masked]<mailto:[email-masked]>; 
>>>>> Cc: [email-masked]<mailto:[email-masked]>; 
>>>>> [email-masked]<mailto:[email-masked]>;
>