[core] Questions and comments on draft-ietf-core-dynlink-05

[Mojan Mohajer <[e-mail]>]

Hi all,
Having read through dynlink draft, have few questions and comments that are listed below:
1) As per section 3, binding entry is unidirectional and only present on one end point. So, the question arises as to what does a binding entry consist of and whether it also includes binding attributes? If that is the case, not sure how this applies when the binding method is Observe? For Observe the binding method will be at destination as per Table 1, while the binding attributes should also be know at the source end.

2) Initial synchronisation with poll and observe methods are under control of destination which can decide when it is ready to start the synchronisation process. However, with the push method this seems to be left entirely to source as to when the synchronisation starts. If the binding table is pre provisioned through a commissioning tool as suggested in section3, then how can the source determine when to start synchronisation process?

3) As currently stated when pmin and/or pmax are not present the elapsed time between two state synchronisations are left to the synchronisation initiator. For interoperability purposes it may be worth being more prescriptive as is the case in LwM2M. For example in LwM2M when pmax is not present it's taken to have infinite value and when pmin is absent it's taken to be 0, i.e. there is no time restriction between two consecutive synchronisations if other conditions are met.

4) As per 3.3.8 if "st" is included with "gt" or "lt" attributes the AND operator is used when evaluating synchronisation condition, e.g. "st" AND "gt", "st" AND "lt", etc. Unfortunately LwM2M uses OR operation in such evaluation. There are valid use cases for both approaches. But it would be nice to settle on a common one or maybe consider having yet another attribute to specify the operation. Admittedly this last suggestion could be a step too far.

5) The note in section 3.3.8 quite reasonably suggests the use of notification band min or max  for synchronisation on a resource value change. This again is somewhat different to LwM2M where an observe on a resource without specifying any of the attributes such as gt, lt, pmin, pmax, etc. is used to achieve the same result. If acceptable it may be worth extending the note listing LwM2M approach as another option? 

6) Introduction section indicates Observe Attributes can either be used with Link Bindings or standalone Observe as in RFC7641. However, section 4.2 indicates that the query string parameters or observe attributes defined in this draft have to be set up through a PUT method beforehand. At the same time examples in Appendix A reinforce the statement in the introduction while example in 4.1 sets up these attributes when creating a binding through POST. LwM2M uses PUT to set up these attributes which effectively attach the attributes to the resource. But it seems these attributes should logically belong to a particular binding rather than an individual resource on its own. That is if a resource appears in more than one binding to other resources it could have different set of attributes in each binding entry? At the same time an Observe with uri-query options specifying these attributes as per Appendix A could be considered as implicit an binding that is still conforming to the rule of attributes being attached to a binding as opposed to an individual resource. 
Best Regards,
Mojan