Subject: [lmap] AD evaluation: draft-ietf-lmap-information-model-16

From: Alissa Cooper <[email-masked]>
Date: Mon, 23 Jan 2017 14:22:25 -0500

I have reviewed this document in preparation for IETF last call. I have a few substantive comments and questions that I’d like to discuss before issuing the LC. I’ve also included some nits and minor comments that should be resolved together with any IETF LC comments.

Substantive comments and questions:

For a number of my comments below, it might be the case that you think the detail I'm asking for does not belong in the information model, but would be more appropriate in a specification of a specific data model or protocol. I'm not particularly wedded to any of these details appearing here, but I do think they need to appear somewhere, so if they're not going to be specified here I think this document needs to explain that data models and/or protocols need to specify them.

= String type definition =

Is it expected that data models and/or protocols will define what character encoding is expected for the string data type? If so, it would be good to say that somewhere.

= Credentials: Section 3.1, 3.2, 3.8, 6 =

I have a couple of questions about how credentials are defined and used in this document:

(1) Is it expected that data models and/or protocols will define the 'credential' type and format? If so, it would help to make that clear up front.

(2) Are ma-preconfig-credentials and ma-config-credentials meant to be credentials only for the MA to be authenticated by a Controller or Collector? I assume that the credentials that allow the MA to authenticate other endpoints, and to protect communications to those endpoints, are stored in ma-channel-credentials, but it would help to clarify which set of credentials each of these fields is referring to.

(3) I'm a little concerned that both ma-config-control-channels and ma-config-credentials are mandatory fields in ma-config-obj, and that the point of having them specified there is to override the pre-configuration information. If I'm understanding correctly, this means that an MA could be preconfigured with certificates it uses to authenticate and encrypt its initial request to a Controller, and the Controller could then respond by saying, "don't use those credentials for yourself or for me, but use these other ones instead." How can an MA then distinguish between a Controller it should trust and one that has been compromised? I know the bootstrapping process is generally out of scope for LMAP, but that scenario seems to imply a security threat that was not specifically contemplated in the framework. Since the fields are being defined here, I think this document needs to discuss these implications, or explain whether there is some (two-way) exchange expected between the MA and the Controller using all the pre-configured credentials that needs to happen before the MA agrees to use different sets of credentials provisioned by the Controller.  

= Section 3.1.1, 3.4.1, 3.5.3 =

I think you need to specify the scope within which uuids are expected to be unique, and whether the same uuids are expected to be re-used for config, logging, and status.

= Section 3.2 =

I think it would be good to provide some guidance about how NOT to construct a group ID. E.g., I would assume putting sensitive information like "low-income neighborhood" or similar in the group ID would be ill-advised, because even within the single administrative domain where MAs are communicating with Controllers and Collectors, there may be people who are authorized to process the measurement data but not know that level of detail about which kind of group a device/connection belongs to. In that kind of case a mapping between an opaque identifier in the group ID and more contextual information on the Controller/Collector back-end would be wise. I think the draft would benefit from some explanation of that here or in Section 6 with a cross-reference back to here.

= Section 3.5.2 =

What would be the cause for defining different versions of the same task? Also, since the two different versions would have the same name (presumably), I think you need to state of the expected scope of uniqueness of the task name.

= Section 3.5.3 =

Why does this object need both an agent ID and a device ID? Is the device ID here expected to be the same as the one that gets pre-configured on the device? What is an MA supposed to put in the device-id field defined here if there was no device ID pre-configured (since in pre-configuration it's an optional field)?

= Section 3.5.4 =

Are ma-status-schedule-invocations, ma-status-schedule-suppressions, and ma-status-schedule-overlaps meant to report counters over all of time, or only since ma-status-last-started? I think this needs to be clarified.

= Section 3.5.5 =

Same question as 3.5.4 for the counters in this section.

= Section 3.9 and 3.9.1 =

"Both measurement and non-measurement
   Tasks have registry entries to enable the MA to uniquely identify the
   Task it should execute and retrieve the schema for any parameters
   that may be passed to the Task.
   ...
A configured task can be referenced by its name and it
   contains a set of URIs to link to registry entries or a local
   specification of the task.
   ...
ma-task-functions:        A possibly empty unordered set of registry
                             entries identifying the functions of the
                             configured task."

I have a couple of questions about this:

(1) Are there any registries being defined for non-measurement tasks, or is this just indicating that such registries could be created? I think it would help to clarify since there is obviously the metrics registry for measurement tasks.

(2) I don't understand "or a local specification of the task." Is that local specification supposed to be represented with a local URI, the same as other registry objects? Or if not, is ma-task-functions not properly defined, since it's possible to reference something other than a registry entry there?

= Section 3.10.1 =

I don't understand why ma-registry-role is defined here. In draft-ietf-ippm-metric-registry, the role is part of the registry entry, so by specifying the URI, one should know which role is the appropriate one for that entry. 

Nits and minor comments:

= Section 1 =

s/Large Measurement platform/Large-Scale Measurement platform/

= Section 3 =

(1) s/(from a measurement to reporting or communicating with the Controller)/(including measurements or reporting or communicating with the Controller)/

(2) It seems a bit odd that Action first appears in Figure 1 but is not included in the enumerated list of objects above it.

(3) "Every Action contained in a Schedule is defined as a Task. ... Tasks can implement a variety of different types of Actions." I think this will be confusing to readers because it's circular. It sounds like all Actions are Tasks but Tasks are comprised of Actions; I think the abstraction needs to be explained better, and made consistent. See also sections 3.3 and 3.7: "An Action is a Task with additional specific parameters." I think it would be better to define what an Action is once at its earliest use.

= Section 3.1.1 =

s/set of tasks objects/set of task objects/

= Section 3.2 =

OLD
The reporting of a
   Group ID without the MA ID allows the MA to remain anonymous

NEW
The reporting of a
   Group ID without the MA ID may allow the MA to remain anonymous

(Rationale: Given all of the other data and potential identifiers the MA may report, it may still be possible for a Collector or other entity to identify the MA -- not providing an agent ID helps, but does not guarantee anonymity.)

= Secion 3.3 =

s/This enabled fine/This enables fine/

= Section 3.3.2 =

Please add a citation for POSIX.2 fnmatch().

= Section 3.5.4, 3.5.5, and 3.5.6 =

To reduce redundancy I would suggest defining the values 'enabled,' 'suppressed,' 'disabled,' and 'running' outside of all of these sections one time and then within the field definitions just saying which values are valid for each field that uses them.

= Section 3.6 =

s/Where the Configuration/Whereas the Configuration/

(Right? I couldn't quite parse the sentence.)

= Section 3.6.2 =

I think it would be good to provide a short explanation in the text as to why RFC 3339 format is not being used for ma-report-result-cycle-number.

= Section 3.8 =

s/it's own/its own/

= Section 6 =

OLD
This would, for example, allow the MA to remain
   anonymous

NEW
This may, for example, allow the MA to remain
   anonymous

(Same rationale as 3.2.)

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 24 Jan 2017 11:03:11 -0500

> On Jan 23, 2017, at 2:22 PM, Alissa Cooper <[email-masked]> wrote:
> 

Just to reinforce this, now that I’m doing a review of draft-ietf-lmap-yang: it seems that the model in draft-ietf-netconf-netconf-client-server defines both the client and server credentials. So if that is supposed to fulfill the channel credentials in the information model, what happens if the ma-config-credentials for the MA are different than the ones in the ma-channel-obj for the MA? Which ones is the MA supposed to use?

Thanks,
Alissa

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Jan 2017 17:07:21 +0100

Alissa,

thanks for your review - much appreciated. Some of the questions
indeed touch on the question 'what needs to be dealt with in an
information model and what can be left out', which I think has no
clear answer. Please see my response inline...

> Is it expected that data models and/or protocols will define what character encoding is expected for the string data type? If so, it would be good to say that somewhere.

My assumption always was that a string means a (possibly restricted)
set of Unicode or ISO/IEC 10646 characters. The '(possibly restricted)'
comes from the fact that data modeling languages such as YANG excludes
certain control characters, surrogate blocks and noncharacters.

I will get back to this at the end.

> (1) Is it expected that data models and/or protocols will define the 'credential' type and format? If so, it would help to make that clear up front.

Yes. I will get back to this at the end.
 
> (2) Are ma-preconfig-credentials and ma-config-credentials meant to be credentials only for the MA to be authenticated by a Controller or Collector? I assume that the credentials that allow the MA…

This is a very good question and I do not recall how we got to what we
have. The channel credentials are the credentials used between an MA
and a Controller or Collector. It is less clear what the other device
credentials are really used for. Trevor, do you recall and can you
clarify the situation? My interpretation is that the configured
credentials are, for example, the credentials needed for trusted X.509
authorities, i.e., they are not channel specific - the credentials an
MA has to use for a specific channel but the credentials needed to
verify the credentials of a remote peer. Trevor?

> (3) I'm a little concerned that both ma-config-control-channels and ma-config-credentials are mandatory fields in ma-config-obj, and that the point of having them specified there is to override the…

I think the assumption here is that the MA trusts the controller which
has credentials matching the MA's pre-configured credentials. If this
trusted controller then later installs new credentials, this leads to
a trust relationship to another controller. Are you requesting that this
should be more clearly discussed in the Security Considerations? Or are
you saying this is a bad idea and we should not allow a controller to
provision any credentials?

> I think you need to specify the scope within which uuids are expected to be unique, and whether the same uuids are expected to be re-used for config, logging, and status.

I think the idea is to use version 4 uuids which have a very low
probability of collision. Generally, the expectation is that these
uuids are unique within an installation of a large-scale measurement
system.

I will get back to this at the end.

> I think it would be good to provide some guidance about how NOT to construct a group ID. E.g., I would assume putting sensitive information like "low-income neighborhood" or similar in the group ID…

I agree. And I think this is not only relevant for group IDs but equally
applies to tags or other names that can be freely choosen. What about this
at the end of the Security Considerations:

   [...] In addition, users of this Information Model are
   advised to choose identifiers for Group IDs, tags or names of
   information model objects (e.g., configured tasks, schedules or
   actions) that do not reveal any sensitive information to people
   authorized to process measurement results but who are not authorized
   to know details about the Measurement Agents that were used to
   perform the measurement.
 
> What would be the cause for defining different versions of the same task? Also, since the two different versions would have the same name (presumably), I think you need to state of the expected sco…

Names of objects are generally assumed to be unique within an MA.

The version here is essentially used to be able to distinguish
different versions of an implementation of a given metric. I might
have MAs with an old version of a metric implementation with specific
bugs and I might have MAs with a new version of a metric
implementation with different kind of bugs.

> Why does this object need both an agent ID and a device ID? Is the device ID here expected to be the same as the one that gets pre-configured on the device? What is an MA supposed to put in the dev…

We could make the ma-status-device-id optional to be consistent.

> Are ma-status-schedule-invocations, ma-status-schedule-suppressions, and ma-status-schedule-overlaps meant to report counters over all of time, or only since ma-status-last-started? I think this ne…

Counters are not expected to persist across reboots.

I will get back to this at the end.
 
> Same question as 3.5.4 for the counters in this section.

Same as above.

> (1) Are there any registries being defined for non-measurement tasks, or is this just indicating that such registries could be created? I think it would help to clarify since there is obviously the…

Creating an LMAP task registry was briefly discussed on the mailing
list but so far no concrete proposal has been written. I think the
definition in section 3.9 is actually fine since it does not refer
explicitely to the IPPM metrics registry.

> (2) I don't understand "or a local specification of the task." Is that local specification supposed to be represented with a local URI, the same as other registry objects? Or if not, is ma-task-fun…

The set of referenced regristry entry entries can be empty. The phrase
'or a local specification of the task' is indeed confusing. What is
meant here is a task that is essentially well-known by its name. For
example, there is a task called 'traceroute' or 'iperf' and I expect
it to do a traceroute or to run iperf measurements. Perhaps the text
should be changed to read:

   A configured task can be referenced by its name and it
   contains a possibly empty set of URIs to link to registry entries.

> I don't understand why ma-registry-role is defined here. In draft-ietf-ippm-metric-registry, the role is part of the registry entry, so by specifying the URI, one should know which role is the appr…

An entry in the metrics registry may define multiple roles. The
ma-registry-role selects which of these roles are instantiated.
 
> s/Large Measurement platform/Large-Scale Measurement platform/

fixed

> (1) s/(from a measurement to reporting or communicating with the Controller)/(including measurements or reporting or communicating with the Controller)/

fixed

> (2) It seems a bit odd that Action first appears in Figure 1 but is not included in the enumerated list of objects above it.

I agree - Actions came in later and it still shows. I will see what I

> (3) "Every Action contained in a Schedule is defined as a Task. ... Tasks can implement a variety of different types of Actions." I think this will be confusing to readers because it's circular. It…

What about this (right below Figure 1):
 
   The primary function of an MA is to execute Schedules.  A Schedule,
   which is triggered by an Event, executes a number of Actions.  An
   Action refers to a Configured Task and it may feed results to a
   Destination Schedule.  Both, Actions and Configured Tasks can provide
   parameters, represented as Action Options and Task Options.

> s/set of tasks objects/set of task objects/

fixed

> (Rationale: Given all of the other data and potential identifiers the MA may report, it may still be possible for a Collector or other entity to identify the MA -- not providing an agent ID helps,…

fixed

> s/This enabled fine/This enables fine/

fixed

> Please add a citation for POSIX.2 fnmatch().

done
 
> To reduce redundancy I would suggest defining the values 'enabled,' 'suppressed,' 'disabled,' and 'running' outside of all of these sections one time and then within the field definitions just sayi…

I do no think the benefit is worth the effort. We do not have any notion
of user defined types so far and introducing it to save a few words does
in my view not make the specification clearer.

> (Right? I couldn't quite parse the sentence.)

Yes, fixed.

> I think it would be good to provide a short explanation in the text as to why RFC 3339 format is not being used for ma-report-result-cycle-number.

The point is that the cycle-number is a fixed-point _number_.

> s/it's own/its own/

fixed

> This may, for example, allow the MA to remain

fixed

To address the questions (above) concerning the semantics of several
base types we have used, I think it makes sense to add the following
to section 2:

   The object definitions use a couple of base types that are defined as
   follows:

   int         A type representing signed or unsigned integer numbers.
               This information model does not define a precision nor
               does it make a distinction between signed and unsigned
               number ranges.  This type is also used to represent
               enumerations.

   boolean     A type representing a boolean value.

   string      A type representing a human-readable strings consisting
               of a (possibly restricted) subset of Unicode and ISO/IEC
	       10646 [ISO.10646] characters.

   datetime    A type representing a date and time using the Gregorian
               calendar.  The datetime format MUST conform to RFC 3339
               [RFC3339].

   uuid        A type representing Universally Unique IDentifier (UUID(
               as defined in RFC 4122 [RFC4122].  The UUID values are
               expected to be unique within an installation of a large-
               scale measurement system.

   uri         A type representing a Uniform Resource Identifier as
               defined in STD 66 [RFC3986].

   ip-address  A type representing an IP address.  This type supports
               both IPv4 and IPv6 addresses.

   counter     A non-negative integer that monotonically increases.
	       Counters may have discontinuities and they are not
	       expected to persist across restarts.

   credentials An opaque type representing credentials needed by a
               cryptographic mechanism to security communication.  Data
               models must expand this opaque type as needed and
               required by the security protocols utilized.

   data        An opaque type representing data obtained from
               measurements.

   Names of objects are generally assumed to be unique within an
   implementation.

A diff of -16 to my working copy (of -17) can be found here:

  http://beadg.de/lmap/

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Jan 2017 21:28:01 +0100

Trevor and Phil,

do you recall the reason why we have channel credentials and MA global
credentials? How are the MA global credentials supposed to be used?

/js

On Tue, Jan 24, 2017 at 11:03:11AM -0500, Alissa Cooper wrote:
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: <[email-masked]>
Date: Wed, 25 Jan 2017 09:02:11 +0000

Initially the MA credentials were the private credentials of the MA and the channel credentials were the public credentials for each channel end-point.

Trevor.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 24 January 2017 20:28
To: Burbridge,T,Trevor,TUB8 R <[email-masked]>; Eardley,PL,Philip,TUB8 R <[email-masked]>
Cc: [email-masked]; Alissa Cooper <[email-masked]>
Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16

Trevor and Phil,

do you recall the reason why we have channel credentials and MA global credentials? How are the MA global credentials supposed to be used?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jan 2017 10:18:35 +0100

Trevor,

this is also the explanation I came up with but the document does not
really explain this. Alissa, would this resolve your comment if I try
to add text that tries to explain this distinction? Would it help to
add examples?

- SSH host keys are I think examples of MA credentials while SSH user
  authentication keys and authorization lists are channel
  credentials.

- X.509 certificates defining trust to X.509 root authorities are
  examples of MA credentials. while X.509 client ceritifcates for TLS
  communication are channel credentials.

(Lets see whether I got this right. ;-)

/js

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 25 Jan 2017 10:52:08 -0500

Hi Juergen,

Responses below. I trimmed out areas that don’t need a response.

> On Jan 24, 2017, at 11:07 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Alissa,
> 

Sounds good. 

> Names of objects are generally assumed to be unique within an MA.

I think it’s worth saying that explicitly.

> implementation with different kind of bugs.

Is there a reason that level of detail is needed on a metric-by-metric basis, as opposed to just using a software version number for the implementation as a whole?

> We could make the ma-status-device-id optional to be consistent.

That sounds better but I still think you need to justify it being there, even as optional. Up to this point I thought the device ID was used potentially to generate an agent ID during configuration, but after that it seems to create unnecessary risk to include it in status reports.

> explicitely to the IPPM metrics registry.

I think it would help if it said "Both measurement and non-measurement Tasks may have registry entries …."

>   contains a possibly empty set of URIs to link to registry entries.

That would help, yes.

> ma-registry-role selects which of these roles are instantiated.

Got it, ok.

>   parameters, represented as Action Options and Task Options.

Some minor tweaks:

The primary function of an MA is to execute Schedules.  A Schedule,
  which is triggered by an Event, executes a number of Actions.  An
  Action is a Configured Task and it may feed results to a
  Destination Schedule.  Both Actions and Configured Tasks can provide
  parameters, represented as Action Options and Task Options.

> The point is that the cycle-number is a fixed-point _number_.

Ok, fair enough.

> 	       10646 [ISO.10646] characters.

s/strings/string/

>               cryptographic mechanism to security communication.  

s/security/secure/

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 25 Jan 2017 10:57:19 -0500

Juergen,

> On Jan 25, 2017, at 4:18 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Trevor,
> 

Explanation and examples would help, especially if some clear delineation about what belongs in each credential set can be given, albeit while remaining generic. But the bigger question is ...

>  communication are channel credentials.

… can you explain why you want the controller to be able to change each of these on the MA, from how they were pre-configured?

Thanks,
Alissa

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Jan 2017 09:53:54 +0100

> Responses below. I trimmed out areas that don’t need a response.

Trimming even further...

> Is there a reason that level of detail is needed on a metric-by-metric basis, as opposed to just using a software version number for the implementation as a whole?

You can have monolithic or modular implementations. In a modular
implementation, the version of a metric implementation may change
without the change of the version of the MA. People with measurement
experience have often stated how important it is to know precisely
which version of software was involved in a measurement since this
often is essential to understand artifacts observed during data
analysis.

> That sounds better but I still think you need to justify it being there, even as optional. Up to this point I thought the device ID was used potentially to generate an agent ID during configuration…

What kind of risks? The device-id is one piece of information that may
be used by a controller while assigning an agent-id. So it is exposed
to a controller anyway. And the model does not make any statement that
an agent-id can only assigned during an initial bootstrap process,
i.e., a controller may have reasons to re-bootstrap (is that a word?)
the LMAP agent.

> I think it would help if it said "Both measurement and non-measurement Tasks may have registry entries …."

You want me to repeat this sentence

   [...] Both measurement and non-measurement
   Tasks have registry entries to enable the MA to uniquely identify the
   Task it should execute and retrieve the schema for any parameters
   that may be passed to the Task.

that is already in section 3.9 in the description of ma-task-functions
(section 3.9.1)?

>   parameters, represented as Action Options and Task Options.

Well, an Action refers to a Configured Task, I do not think it is
correct to say an Action is a Configured Task. I think the text I
proposed is more precise.

fixed

fixed

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Jan 2017 10:52:21 +0100

> … can you explain why you want the controller to be able to change each of these on the MA, from how they were pre-configured?

I will try to write some text. Here is the story line: The channel
credentials are relatively obvious (I think) since (i) credentials
often have an expire time (e.g., valid until in X.509 certificates)
and (ii) a controller may want to push channel credentials that are
necessary to talk to a collector or a different controller - i.e., an
initial bootstrap controller may want to redirect a device to another
controller taking care of the device subsequently. If you think about
this, then it may indeed be necessary to update MA credentials as well
in order to allow the MA to verify the credentials presented by a
collector or a different controller.

For an MA embedded in a more complex system, the management of the
credentials may not be controller specific or it may be done entirely
by a different component. In the YANG models, the LMAP model does not
deal with credential management at all. Instead, credentials are deal
with with the NETCONF/RESTCONF data models. And they again refer to
security protocol specific models (for SSH and TLS) and these again
refer to a keystore data model. All this is relatively complex and all
the LMAP information models says is that the functionality to manage
credentials is needed - but it leaves it opaque.

Do you think it is wrong to say that an LMAP controller may need to
update channel and MA credentials in the information model?

/js

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 30 Jan 2017 10:45:03 -0500

Hi Juergen,

> On Jan 26, 2017, at 3:53 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Ok.

> i.e., a controller may have reasons to re-bootstrap (is that a word?)

Since the device ID can be an ID that is re-used in all kinds of contexts (e.g., a MAC address), its use creates the potential to correlate LMAP activities with other activities in which the device is engaged, and potentially to identify the user. Again thinking about whether there might be different access control domains *within* a controller, it seems unnecessary to expose something like a MAC address in a status reporting context if the MA can be uniquely identified by the agent ID. Then only the code/people that deal with configuration need authorization to process MAC addresses or other device IDs.

> that is already in section 3.9 in the description of ma-task-functions

No, sorry, I was just suggesting that you add the word “may."

> correct to say an Action is a Configured Task.

Then why does the text in later sections say "An Action is a Task with additional specific parameters”? That is where I am confused.

Thanks,
Alissa

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Jan 2017 10:44:27 +0100

> Since the device ID can be an ID that is re-used in all kinds of contexts (e.g., a MAC address), its use creates the potential to correlate LMAP activities with other activities in which the device…

The status reports go to the LMAP controller, so I do not really see
why there is a specific risk since the controller has access to the
device ID anyway.

> No, sorry, I was just suggesting that you add the word “may."

Ah, I see - I have added 'may'.

> Then why does the text in later sections say "An Action is a Task with additional specific parameters”? That is where I am confused.

I see. I replaced "Action is a Task" with "Action extends a Configured
Task".

/js

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 31 Jan 2017 09:15:52 -0500

> On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>> 
> 

I still am missing what is the rationale for sending the device ID in the status reports. I thought the agent ID was meant to uniquely identify the MA.

Alissa

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Jan 2017 20:47:57 +0100

> I still am missing what is the rationale for sending the device ID in the status reports. I thought the agent ID was meant to uniquely identify the MA.

So here we go. I propose the following change:

  - The ma-status-agent-id becomes optional.
  - The ma-status-device-id becomes mandatory again.

Rationale:

  If a device does not yet have an MA-ID, then the device-id must be
  accessible such that the controller can configure an MA-ID.

/js