Ballot for draft-ietf-lmap-yang
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
I only skimmed the document, but I have no objections.
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?
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."
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