A YANG Data Model for LMAP Measurement Agents
Note: This ballot was opened for revision 11 and is now closed.
Alissa Cooper Yes
(Jari Arkko) No Objection
(Alia Atlas) No Objection
Deborah Brungard No Objection
(Ben Campbell) No Objection
(Benoît Claise) (was Discuss, No Objection) No Objection
(Stephen Farrell) No Objection
(Joel Jaeggli) No Objection
Suresh Krishnan No Objection
Comment (2017-03-15 for -11)
Figure 1: There is a typo (actually four typos) in the yang module name ietf-lmap-comman.yang should be ietf-lmap-common.yang instead
Mirja Kühlewind (was Discuss) No Objection
Comment (2017-03-21 for -11)
Thanks for the feedback! Still some comments: - Maybe make RFC7594 a normative reference. - It could be good to give some further guidance on how connectivity is established. Something like, in most cases the controller will connect the MA and the controller should make sure that it reconnects frequently based on the timeout configuration of the MA. If the MA e.g. is behind a NAT, the MA must establish the initial connection and try to reconnect when the timeout expires. Btw. is it enough to open a transport connection or do you mean by checking connectivity that there also should be some data transmitted to ensure that the controller is no only reachable but also active? - I still think there might be further information needed on bootstrapping. This draft only says: "Pre-Configuration Information: This is not modeled explicitly since bootstrapping information is outside the scope of this data model."
Alexey Melnikov No Objection
Comment (2017-03-16 for -11)
I only skimmed the document, but I have no objections.
(Kathleen Moriarty) No Objection
Comment (2017-03-13 for -11)
The security considerations looks good, but can't YANG also be accessed via RESTCONF? What considerations are needed for that? I thunk we went through this for I2RS, do considerations for RESTCONF apply to this YANG module?