jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-dynlink

Commentary: Signed - off - by :   < the reasons stated in . 
 Hi , OMA LwM2 M is using Minimum Period ( pmin ) and Maximum Period ( pmax ) attributes . The DynLink draft has this requirement : In its version 1.0 , LwM2 M had a different version of this requirement in the form : Thus having pmax equal to pmin was allowed . In LwM2 M 1.1 we aligned this requirement with the DynLink one , making pmin equal to pmax forbidden . However , it was that having pmin equal pmax is a valid use case if the client wants the notification to be sent exactly every N seconds . Is there a strong opinion on forbidding pmax to be equal to pmin , or are people open to changing the Dynlink requirement ? Regards 
 After the discussion at IETF 109 , I think we can agree that there are no strong opinions against allowing pmax to be greater than or equal to pmin in the draft . However in order to avoid any ambiguity in interpretation , do we want reflect the discussion so far , so that the draft has pmax = = pmin , specifically for this use case , ie when this condition is met , then the CoAP server sends ( is it a MUST / SHOULD / MAY ? ) the resource representation every N seconds ? Also how does the client then cancel this request ? 
 Closing this issue , with the draft allowing pmax to have equality to pmin
When present, the maximum period indicates the maximum time, in
seconds, between two consecutive notifications (whether or not the
resource value has changed).  In the absence of this parameter, the
maximum period is up to the server.  The maximum period MUST be
greater than zero and MUST be greater than the minimum period
parameter (if present) otherwise the receiver MUST return a CoAP
error code 4.00 "Bad Request" (or equivalent).
When present, the maximum period indicates the maximum time, in
seconds, between two consecutive notifications (whether or not the
resource value has changed).  In the absence of this parameter, the
maximum period is up to the server.  The maximum period MUST be
greater than zero and MUST be greater than, or equal to, the minimum
period parameter (if present) otherwise the receiver MUST return a
CoAP error code 4.00 "Bad Request" (or equivalent).
Draft: draft-ietf-core-dynlink

Commentary: I 've created a pull request to incorporate the exec binding method in the draft . This brings it in line with and also now has a reference to the draft itself . It would be great if you can quickly review the proposed text and see if you are ok with it 
 Now merged , after review comments received from to highlight differences between the  and  binding methods
When the Push method is assigned to a binding, the source endpoint
sends PUT requests to the destination resource when the Conditional
Notification Attributes are satisfied for the source resource.  The
source endpoint SHOULD only send a notification request if any
included Conditional Notification Attributes are met.  The binding
entry for this method MUST be stored on the source endpoint.
The Push method can be used to allow a source endpoint to replace an
outdated resource state at the destination with a newer
representation.  When the Push method is assigned to a binding, the
source endpoint sends PUT requests to the destination resource when
the Conditional Notification Attributes are satisfied for the source
resource.  The source endpoint SHOULD only send a notification
request if any included Conditional Notification Attributes are met.
The binding entry for this method MUST be stored on the source
endpoint.
An alternative means for a source endpoint to deliver change-of-state
notifications to a destination resource is to use the Execute Method.
While the Push method simply updates the state of the destination
resource with the representation of the source resource, Execute can
be used when the destination endpoint wishes to receive all state
changes from a source.  This allows, for example, the existence of a
resource collection consisting of all the state changes at the
destination endpoint.  When the Execute method is assigned to a
binding, the source endpoint sends POST requests to the destination
resource when the Conditional Notification Attributes are satisfied
for the source resource.  The source endpoint SHOULD only send a
notification request if any included Conditional Notification
Attributes are met.  The binding entry for this method MUST be stored
on the source endpoint.
Note: Both the Push and the Execute methods are examples of Server
Push mechanisms that are being researched in the Thing-to-Thing
Research Group (T2TRG) I-D.irtf-t2trg-rest-iot.
Binding methods now support both POST and PUT operations for
server push.