Subject: [lmap] optional leafs due to sensitity concerns

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Oct 2016 19:38:16 +0200

Hi,

some objects in the information model (e.g., agent-id) are marked
optional because of sensitivity considerations. Since there is an
access control model for NETCONF (and RESTCONF), it would feel more
natural to make these objects mandatory in YANG and leave it to the
access control model to prevent access to them in deployments where
this is needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 10 Oct 2016 19:12:42 +0000

Juergen,
The agent id in the report is between the agent and the data collector - It's a privacy issue where the agent id was not to be even transmitted if the report-agent-id was false.

Does the access control model allow these kinds of checks for presence of fields to be transmitted. 

Authorization for access (CRUD) is different than even transmitting the field (or value in the field depending on your protocol).

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, October 10, 2016 12:38 PM
To: [email-masked]
Subject: [lmap] optional leafs due to sensitity concerns

Hi,

some objects in the information model (e.g., agent-id) are marked optional because of sensitivity considerations. Since there is an access control model for NETCONF (and RESTCONF), it would feel more natural to make these objects mandatory in YANG and leave it to the access control model to prevent access to them in deployments where this is needed.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Oct 2016 21:45:34 +0200

Tim,

I agree, the agent-id is not a problem since we do have an explicit
control whether this is included in a report. I actually stumbled
about similar text (which might be a copy and paste error) for the
configurable device-id but if we end up removing the configurable
device-id (see other thread), then this becomes a mood point.

Looking at leaf report-agent-id, I see:

        description
          "The 'report-agent-id' controls whether the
           'agent-id' is reported to collectors if the
           'group-id' is configured. If the 'group-id'
           is not configured, the agent-id is always
           reported.";

This seems weird since removing a group-id suddenly exposes an
agent-id. I kind of dislike such side-effects. Checking the
information model, I see:

   ma-config-report-agent-id:          An optional flag indicating
                                       whether the identifier (ma-
                                       config-agent-id) should be
                                       included in reports.  The default
                                       value is false.

This seems to be simpler and hence I suggest to remove the last
sentence from the description of the report-agent-id.

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 10 Oct 2016 20:00:58 +0000

Juergen

In the information model - the text in section 3.2 says:
Where the Measurement Group ID is set
an additional flag (the Report MA ID flag) is required to control
whether the Measurement Agent ID is also to be reported. The
reporting of a Group ID without the MA ID allows the MA to remain
anonymous, which may be particularly useful to prevent tracking of
mobile MA devices.

So yes - we will report a MA ID if there is no Group ID or when the Group ID exists and the report MA ID is false.

So the group id allows the capability for MA ID to remain anonymous. The feature is invoked by setting the report MA ID field to false.
What has to happen is worst case either a Group ID or MA ID is always reported. Sometimes both will be reported.

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, October 10, 2016 2:46 PM
To: Carey, Timothy (Nokia - US) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lmap] optional leafs due to sensitity concerns

Tim,

I agree, the agent-id is not a problem since we do have an explicit control whether this is included in a report. I actually stumbled about similar text (which might be a copy and paste error) for the configurable device-id but if we end up removing the configurable device-id (see other thread), then this becomes a mood point.

        description

This seems weird since removing a group-id suddenly exposes an agent-id. I kind of dislike such side-effects. Checking the information model, I see:

This seems to be simpler and hence I suggest to remove the last sentence from the description of the report-agent-id.

On Mon, Oct 10, 2016 at 07:12:42PM +0000, Carey, Timothy (Nokia - US) wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Oct 2016 22:22:17 +0200

> So yes - we will report a MA ID if there is no Group ID or when the Group ID exists and the report MA ID is false.

OK. But why? Why is the flag to suppress the agent id only relevant if
there is a group id? Isn't it confusing if one sets report-agent-id to
'false' but the agent continues to report agent-ids until there is
finally a group-id set? I think this is a real surprise for someone
who has not read the fine print. I think the design would be simpler
and less surprising if the report-agent-id would always enable/disable
the reporting of the agent-id. (And yes, if you set report-agent-id to
false and you do not set a group-id, you get a pretty anonymous
report. But I think this is better than sending the agent-id even
though the report-agent-id is false.)

> What has to happen is worst case either a Group ID or MA ID is always reported. Sometimes both will be reported.

The worst case is someone setting report-agent-id to false and the MA
still sending the agent-id just because a group-id is missing. I think
this design kind of violates the principle of least astonishment.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 10 Oct 2016 20:28:18 +0000

Juergen,

I think it is because they want at least one or the other reported. Such that an anonymous agent would still have a group id to associate the results.
Yes indeed this rule can be easily misinterpreted - I guess we ought to have clarifying text in the descriptions in the reporting - maybe the attribute should be named
report-agent-id-with-group?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, October 10, 2016 3:22 PM
To: Carey, Timothy (Nokia - US) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lmap] optional leafs due to sensitity concerns

On Mon, Oct 10, 2016 at 08:00:58PM +0000, Carey, Timothy (Nokia - US) wrote:
> whether the Measurement Agent ID is also to be reported. The reporting 
> of a Group ID without the MA ID allows the MA to remain anonymous, 
> which may be particularly useful to prevent tracking of mobile MA 
> devices.
> 

OK. But why? Why is the flag to suppress the agent id only relevant if there is a group id? Isn't it confusing if one sets report-agent-id to 'false' but the agent continues to report agent-ids until there is finally a group-id set? I think this is a real surprise for someone who has not read the fine print. I think the design would be simpler and less surprising if the report-agent-id would always enable/disable the reporting of the agent-id. (And yes, if you set report-agent-id to false and you do not set a group-id, you get a pretty anonymous report. But I think this is better than sending the agent-id even though the report-agent-id is false.)

> What has to happen is worst case either a Group ID or MA ID is always reported. Sometimes both will be reported.

The worst case is someone setting report-agent-id to false and the MA still sending the agent-id just because a group-id is missing. I think this design kind of violates the principle of least astonishment.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Oct 2016 22:36:30 +0200

Tim,

why not simply make the design simpler and at the same time less
surprising?

BTW, having a report without an agent-id and a group-id is of the same
value as a report with just a group-id if all MAs have the same
group-id value set. Why would the later be allowed by the model but
the former be disallowed by the model?

I vote for having report-agent-id as a simple unconditional boolean
flag controlling the inclusion of the agent-id in reports.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 10 Oct 2016 20:43:39 +0000

Juergen,

Because the service provider will want to correlate the results based on the MA or Group.

I am for simplification as well - So long as we ensure at least one or the other is always reported - that was the intent.
You can say that the report-agent value cannot be false unless a group-id is present... Maybe that makes it simpler. Agents will error otherwise upfront.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, October 10, 2016 3:37 PM
To: Carey, Timothy (Nokia - US) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lmap] optional leafs due to sensitity concerns

Tim,

why not simply make the design simpler and at the same time less surprising?

BTW, having a report without an agent-id and a group-id is of the same value as a report with just a group-id if all MAs have the same group-id value set. Why would the later be allowed by the model but the former be disallowed by the model?

I vote for having report-agent-id as a simple unconditional boolean flag controlling the inclusion of the agent-id in reports.

/js

On Mon, Oct 10, 2016 at 08:28:18PM +0000, Carey, Timothy (Nokia - US) wrote:
> Yes indeed this rule can be easily misinterpreted - I guess we ought 
> to have clarifying text in the descriptions in the reporting - maybe the attribute should be named report-agent-id-with-group?
> 
> > Where the Measurement Group ID is set an additional flag (the Report 
> > MA ID flag) is required to control whether the Measurement Agent ID 
> > is also to be reported. The reporting of a Group ID without the MA 
> > ID allows the MA to remain anonymous, which may be particularly 
> > useful to prevent tracking of mobile MA devices.
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Oct 2016 10:49:33 +0200

> based on the MA or Group.

Cool, the service provider can set things up accordingly.
 
> I am for simplification as well - So long as we ensure at least one
> or the other is always reported - that was the intent.

This violates the separation of policy from mechanism. You try to
encode a policy into a mechanism. I am against that. Having this flag
conditional adds complexity for no real value. Setting report-agent-id
to false and then sending agent-ids breaks the principle of least
astonishment. Creating a longer name to express that this flag has a
convoluted logic does not solve the issue. What if in the future even
more IDs are added? Sorry, this is simply bad design.

> You can say that the report-agent value cannot be false unless a
> group-id is present... Maybe that makes it simpler. Agents will
> error otherwise upfront.

No, it just shows that there is complexity without any real
value. There is nothing wrong with allowing no agent-id and no
group-id - whether this is useful is up to the controller (and
collector) to decide. (There are indeed other ways to identify
results, not reporting the agent-id for example is pointless if
I tag all schedules with an agent specific value.)

Chairs, can you help resolve this? Document updates are blocked on
this.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Fri, 14 Oct 2016 11:14:38 +0000

Juergen,

Then suggest a design fix that allows the controller to tell the agent to report one of the options:
1) Agent-ID
2) Group-ID
3) Agent-ID and Group-ID

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, October 14, 2016 3:50 AM
To: Carey, Timothy (Nokia - US) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lmap] optional leafs due to sensitity concerns

 
> I am for simplification as well - So long as we ensure at least one or 
> the other is always reported - that was the intent.

This violates the separation of policy from mechanism. You try to encode a policy into a mechanism. I am against that. Having this flag conditional adds complexity for no real value. Setting report-agent-id to false and then sending agent-ids breaks the principle of least astonishment. Creating a longer name to express that this flag has a convoluted logic does not solve the issue. What if in the future even more IDs are added? Sorry, this is simply bad design.

> group-id is present... Maybe that makes it simpler. Agents will error 
> otherwise upfront.

No, it just shows that there is complexity without any real value. There is nothing wrong with allowing no agent-id and no group-id - whether this is useful is up to the controller (and
collector) to decide. (There are indeed other ways to identify results, not reporting the agent-id for example is pointless if I tag all schedules with an agent specific value.)

Chairs, can you help resolve this? Document updates are blocked on this.

/js

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 26 Oct 2016 18:51:17 +0000

We are now a few days out from the Oct 31 cutoff for draft submissions. I
have a few questions regarding the Information-model-11 draft.

  1. Are we still at a deadlock on the ability for a controller to signal
which ID for an MA to use in reporting discussion?

  2. If so is there a plan forward or possible new design being
contemplated behind the scenes?

It would be nice to hear from more than just Time and Juergen in this
discussion. It¹s pretty easy for two parties to reach a deadlock. It is
much harder for 5 or 6 people so it would be nice if others want to see
this draft progress to completion to weigh in on the discussion.

Thanks,
Jason

On 10/14/16, 5:14 AM, "lmap on behalf of Carey, Timothy (Nokia - US)"
<[email-masked] on behalf of [email-masked]> wrote:

>This violates the separation of policy from mechanism. You try to encode
>a policy into a mechanism. I am against that. Having this flag
>conditional adds complexity for no real value. Setting report-agent-id to
>false and then sending agent-ids breaks the principle of least
>No, it just shows that there is complexity without any real value. There
>is nothing wrong with allowing no agent-id and no group-id - whether this
>is useful is up to the controller (and
>collector) to decide. (There are indeed other ways to identify results,
>not reporting the agent-id for example is pointless if I tag all
>schedules with an agent specific value.)
>
>_______________________________________________
>lmap mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lmap

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 31 Oct 2016 13:39:57 +0000

>   1. Are we still at a deadlock on the ability for a controller to signal which ID
> for an MA to use in reporting discussion?
> 
>   2. If so is there a plan forward or possible new design being contemplated
> behind the scenes?
> 
> It would be nice to hear from more than just Tim and Juergen in this
> discussion. It¹s pretty easy for two parties to reach a deadlock. It is much
> harder for 5 or 6 people so it would be nice if others want to see this draft
> progress to completion to weigh in on the discussion.

For me, I would be satisfied with any solution that allows the controller to tell the agent 
to report one of the following:
1) Agent-ID
2) Group-ID
3) Agent-ID and Group-ID
Tim did suggest a way to do this, which I had no problem with. But there are definitely other ways to make this happen. If no other way is suggested, then I would like to stick with the mechanism Tim proposed. If another way is suggested (in a timely manner), I'm happy to consider it. 
Barbara

---

From: "Weil, Jason A" <[email-masked]>
Date: Mon, 31 Oct 2016 16:47:04 +0000

I was under the impression that we are just talking about the controller
telling the MA to report on one of the options: Agent-ID, Group-ID, or
Agent-ID and Group-ID and not about how these Identifiers get configured
on the agent. I believe this is the email Al was referring to below. Am I
wrong here? This seems like a fairly easy change that we have consensus
for based on the responses on the list.

Jason

On 10/31/16, 10:14 AM, "MORTON, ALFRED C (AL)" <[email-masked]> wrote:

>I'd prefer to follow WG agreements captured in the
>Framework RFC:
>https://tools.ietf.org/html/rfc7594#section-5.4
>
>where Report:  [MA-ID &/or Group-ID],...
>makes one or both of these IDs non-optional,
>and this is consistent with Tim's 10/14 request below.
>
>regards,
>Al
>
>> From: lmap [mailto:[email-masked]] On Behalf Of Weil, Jason
>> Sent: Wednesday, October 26, 2016 2:51 PM
>> To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder
>> Cc: [email-masked]
>> >Then suggest a design fix that allows the controller to tell the agent
>> to
>> >report one of the options:
>> >1) Agent-ID
>> >2) Group-ID
>> >3) Agent-ID and Group-ID
>> >
>> >BR,
>> >Tim
>> >
>> or
>> encode
>> to
>> This E-mail and any of its attachments may contain Time Warner Cable
>> proprietary information, which is privileged, confidential, or subject
>> to copyright belonging to Time Warner Cable. This E-mail is intended
>> solely for the use of the individual or entity to which it is addressed.
>> If you are not the intended recipient of this E-mail, you are hereby
>> notified that any dissemination, distribution, copying, or action taken
>> in relation to the contents of and attachments to this E-mail is
>> strictly prohibited and may be unlawful. If you have received this E-
>> mail in error, please notify the sender immediately and permanently
>> delete the original and any copy of this E-mail and any printout.
>>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 31 Oct 2016 14:14:52 +0000

regards,
Al

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 31 Oct 2016 20:40:06 +0100

Tim,

the obvious solution is to add a boolean report-group-id and the two
booleans report-agent-id and report-group-id determine whether the
agent-id or the group-id (if available) is reported. It is up to the
policy of the controller to set them. No side effects or
inter-dependencies.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 31 Oct 2016 20:51:41 +0100

Can you explain _why_?

Why is it allowed to have all MAs send, lets say, a zero-length
string as a Group-ID? Why is sending no Group-ID disallowed?

My point is that the controller should define what it likes to see
reported to collectors and we should not hardcode a policy here.

/js

---

From: "Weil, Jason" <[email-masked]>
Date: Mon, 31 Oct 2016 19:53:14 +0000

Juergen,

If Tim agrees, could we get this into -12 of the Info Model draft today
before the cutoff?

Tim, does this work for you?

Others members of course should weigh in if you disagree.

Jason

On 10/31/16, 3:40 PM, "lmap on behalf of Juergen Schoenwaelder"
<[email-masked] on behalf of [email-masked]>
wrote:

>>to report one of the options:
>> 1) Agent-ID
>> 2) Group-ID
>> 3) Agent-ID and Group-ID
>>
>> BR,
>> Tim
>>
>> No, it just shows that there is complexity without any real value.
>>There is nothing wrong with allowing no agent-id and no group-id -
>>whether this is useful is up to the controller (and

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 31 Oct 2016 20:33:29 +0000

With the caveat that at least that either one of the Booleans is True so that at least one of the values is reported.

BR,
Tim

-----Original Message-----
From: Weil, Jason [mailto:[email-masked]] 
Sent: Monday, October 31, 2016 2:53 PM
To: Juergen Schoenwaelder <[email-masked]>; Carey, Timothy (Nokia - US) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lmap] optional leafs due to sensitity concerns

Juergen,

If Tim agrees, could we get this into -12 of the Info Model draft today before the cutoff?

Jason

wrote:

>>results, not reporting the agent-id for example is pointless if I tag 
>>all schedules with an agent specific value.)
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 31 Oct 2016 23:24:34 +0100

Al,

why hardcore a requirement to send one of them? Which problem does
this solve? I already pointed out before that tags, for example, may
be used as a means to identify where a measurement is coming from.
(There are in fact many ways to leak the identity of the agent.)

/js

On Mon, Oct 31, 2016 at 08:14:37PM +0000, MORTON, ALFRED C (AL) wrote:
> > Sent: Monday, October 31, 2016 3:52 PM
> > To: MORTON, ALFRED C (AL)
> > Cc: Weil, Jason; Carey, Timothy (Nokia - US); [email-masked]
> > string as a Group-ID? 
> [ACM] 
> Although this is allowed, _why_ would any logical system behave this way?
> 
> > Why is sending no Group-ID disallowed?
> [ACM] 
> Sending no Group-ID _is_ allowed, when sending MA-ID alone.
> That's what &/or allows. The report needs to contain one
> of the forms of identity.
> 
> Al
> 
> > 
> > > > We are now a few days out from the Oct 31 cutoff for draft
> > submissions.
> > > > I
> > > > >On Mon, Oct 10, 2016 at 08:43:39PM +0000, Carey, Timothy (Nokia -
> > US)
> > > > >wrote:
> > > > >> Juergen,
> > > > >>
> > > > >> Because the service provider will want to correlate the results
> > based
> > > > >> on the MA or Group.
> > > > >
> > error
> > > > There
> > > > >is nothing wrong with allowing no agent-id and no group-id -
> > whether
> > > > this
> > results,

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 31 Oct 2016 23:27:18 +0100

Jason,

I think we are running out of time to resolve this before the
cutoff. So I will post what I have and we spin another version
once we got things settled.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 31 Oct 2016 20:14:37 +0000

[ACM] 

[ACM] 

Al