Subject: [Netconf] Last Call on yang-push-17

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Aug 2018 17:28:17 +0000

This message starts a Last Call on draft-ietf-netconf-yang-push-17:

  https://tools.ietf.org/html/draft-ietf-netconf-yang-push-17

This marks the beginning of the last calls on the yang push suite of drafts.
Given the size and number of documents, the chairs decided to break the 
reviews up into pieces so as to get focus on each in turn.  We are choosing
to go top-down, starting with yang-push and ending with the "notif" drafts.
We plan to submit the drafts for publication when they are ready as a 
collective.  The goal is to do all this prior to IETF 103.

We understand that, in reviewing yang-push, there is a need to consider the
subscribed-notifications draft.  We will not be surprised if, in the course
of things, both drafts are updated, even though the review is primarily on
the yang-push draft.

While it's always nice to receive messages of support, at this time, the
question isn't so much if the working group supports the work, than if
the document is ready to progress.  The chairs need to see reviews that
indicate thorough end-to-end reading of the text.  Of course, if there
are any objections, these should be brought forward now as well.

The current version (-17) of this draft was published on July 1st, just
before the IETF 102 meeting.  The datatracker page for the draft is here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push.

Thanks,
Kent (and Mahesh)

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 27 Aug 2018 15:44:46 -0700

I have not reviewed the entire document, but have looked at the Security Considerations section.

The document follows the template defined in OPS-Dir wiki here <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>, but there is a reference in the template that needs to be updated.

s/NETCONF access control model/Network Configuration Access Control Model (NACM)/

Also, can the list of subtrees and data nodes that are sensitive/vulnerable be made a bulleted list. The first item on that list is not one of the nodes. Can it not be intended or moved into the description before the list?

Thanks.

> On Aug 14, 2018, at 10:28 AM, Kent Watsen <[email-masked]> wrote:
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 28 Aug 2018 01:23:14 +0000

It probably goes without saying, but as one of the authors I support moving this document forward.  We are in the process of applying changes per the comments that are received and will post a -18 shortly.  All comments received so far are fairly minor and appear non-controversial.  
--- Alex

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: Tuesday, August 14, 2018 10:28 AM
> To: [email-masked]
> Subject: [Netconf] Last Call on yang-push-17
> 
> reviews up into pieces so as to get focus on each in turn.  We are choosing to
> go top-down, starting with yang-push and ending with the "notif" drafts.
> subscribed-notifications draft.  We will not be surprised if, in the course of
> things, both drafts are updated, even though the review is primarily on the
> yang-push draft.
> 
> question isn't so much if the working group supports the work, than if the
> document is ready to progress.  The chairs need to see reviews that indicate
> thorough end-to-end reading of the text.  Of course, if there are any
> objections, these should be brought forward now as well.
> 
> The current version (-17) of this draft was published on July 1st, just before
> the IETF 102 meeting.  The datatracker page for the draft is here:

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 28 Aug 2018 01:23:14 +0000

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 28 Aug 2018 02:17:43 +0000

Hi,

I believe yang-push-17 is in very good shape and is ready to progress to the next step. Here are my nits/comments/questions, nothing major:

- Both "rpc" and 'RPC" are used, should be "RPC" everywhere?
- Abstract mentions "remote mirroring", should we really assume that these new capabilities all depend on "remote mirroring" of state?
- In Section 2 "Definitions and acronyms", there's mention that the terminology defined in RFCs  7950, 8341 and 8342 is used. We should also mention the subscribed-notifications draft since terminology such as subscribers, receivers etc is defined in that draft.
- Section 2 last bullet should be "The subscription and push mechanisms for datastore updates that are specified..."
- Section 3 should be "a solution that provides a subscription service"
- Section 3.1 "additional parameters such as" implies there are more parameters. I believe there aren't more parameters? If there, add a a reference to the proper section(s)?
- Section 3.1 "... to exhaust of resources" should be "to exhaust resources"
- Section 3.1 "specify the interval which must pass before successive", change "must" to "MUST"?
- Section 3.1 (Page6), change "you might only send when an object is created or deleted" to "the publisher might only send notifications when an object is created or deleted"?
- Section 3.3 first sentence "allow subscribers to receive updates" should be "allow receivers to receive updates"?
- Section 3.3. bullet 3 for YANG patch record, add reference ro RFC8072?
- Section 3.4 2nd paragraph "publisher notifies receivers immediately and reliably whenever...", is it the receivers which are notified in such a situation or is it the subscriber?
- Section 3.5.2 s/datstore/datastore/
- Section 3.5.2 2nd paragraph, text uses past tense "was created", "was deleted", should the present be used instead?
- Section 3.5.2 3rd paragraph, "However a patch must be able...", should that say "patch record"?
- Section 3.5.2 bottom of Page 9, "YANG push" should be changed to "YANG-Push".
- Section 3.6 last sentence mentions "push-update" and "push-change-update", add reference to section 3.7?
- Section 3.7 4th paragraph, sentence "These new "push-update" and "push-change-update" are encoded..." doesn't read well. But I'm not sure how to make it better, maybe add "events" before "are encoded"?
- Section 3.8 3rd paragraph when "establish-subscription-stream-error-info" is mentioned, add a reference?
- Section 3.9 first sentence should finish with "it has proper authorization" (receiver is singular).
- Section 3.9 3rd paragraph first sentence should be "A publisher MAY choose to reject...."
- Section 3.10, first sentence change the last part to "to push on-change updates for some object types"? 
- Section 4.4.1 Figure 10. There seems to be a mistake in the XML example for the error response, we have </error-message> instead of </error-app-tag>
- YANG model P37 presence "indicates an periodic subscription", s/an/a/
- YANG model P38, fix indentation on 2nd line of description
- YANG model P39, leaf nodes kilobytes-limit and kilobytes-estimate, why not use units "kilobyte" and rename these 2 leaf nodes to limit and estimate? 

Regards,
Reshad.

On 2018-08-14, 1:28 PM, "Netconf on behalf of Kent Watsen" <[email-masked] on behalf of [email-masked]> wrote:

    

    Thanks,
    Kent (and Mahesh)

---

From: Qin Wu <[email-masked]>
Date: Tue, 28 Aug 2018 03:23:38 +0000

A few comments on yang-push-17:
I have difficult to understand section 3.2 of yang-push-17:
Section 3.2 of yang-push-17 said:
"
To accomplish this, implementations
   SHOULD support the conceptual authorization model of [RFC8342],
   specifically section 3.2.4.

                         +-----------------+      +--------------------+
     push-update or -->  | datastore node  |  yes | add datastore node |
    push-change-update   | access allowed? | ---> | to update message  |
                         +-----------------+      +--------------------+

      Figure 5: Updated [rfc6536bis] access control for push updates

"
Do we have authorization model in NMDA specification [RFC8342], should we reference to RFC8341?
Section 3.2.4 of RFC8341 is about get and get-config operation which seems not relevant to this section.
Push-update or push-change-update are notification, so we should reference notification access control?
What is the update to RFC6536bis or RFC8341?
If there is update to RFC8341, I think it should be reflected in the front page, right?

Also I think remote mirroring appears only once in the abstract, it will be great to add definition of remote mirroring, it is hard to understand at the first place.

Section 3.11.1 said:
"
Or in case the loss of an update is
   unavoidable, it is critical that the receiver is notified
   accordingly.
"
I am wondering how does the publisher knows the loss of an update?
Do we have mechanism specified for this?

-Qin

    

    Thanks,
    Kent (and Mahesh)

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 28 Aug 2018 14:49:04 +0200

Hi all,

after a thorough review of yang-push-17 I think it is in good shape and 
ready to progress.

A few comments below (more of the nit'esque kind):

In 2. Update Record

It seems to me that "update record" and "update" are used synonymously 
in this document? If so, please add something like the following to the 
definition of update record- NEW:
"In this document, update records are often simply referred to as 
"updates"."

In 3.1. Subscription Model

OLD:
"YANG-push subscriptions are defined using a data model that is itself 
defined in YANG."

I assume there is a good reason for not just phrasing it like - NEW:
"YANG-push subscriptions are defined using a YANG data model."

In 3.1. Dampening period

OLD:
"The dampening period goes into effect every time an update record 
completes assembly."

For clarity (and probably implementation guidance) maybe highlight - NEW:
"The dampening period goes into effect every time an update record 
completes assembly. As long as a dampening period is in effect, the 
Update Trigger functions the same way as with periodic subscriptions, 
using the dampening period as the periodic interval."

In 3.2.

OLD:
"However, there are no guarantees that subsequent requests which 
consider these hints will be accepted."

NEW:
"However, there are no guarantees that subsequent requests, which 
consider these hints, will be accepted."

In 3.3.

OLD:
"In case of a configured subscription, the subscription MAY be suspended."

NEW:
"In case of a configured subscription, the subscription MAY be suspended 
by the publisher."

In 3.3. conceptual process

"access control rules" are rather surprisingly introduced here and then 
never mentioned again.

In 3.3. conceptual process

Same thing with "patch record" the term is only used in the context of 
the conceptual process and never again. Why is this not an update 
record? The relationship to RFC8072 is elaborated on in 3.5.2., but is 
surprising to be found here already.

In 3.3.

OLD:
"A publisher SHOULD reject a request for a subscription if it is 
unlikely that the publisher will be able fulfill the terms of that 
subscription request."

NEW:
"A publisher SHOULD reject a request for a subscription, if it is 
unlikely that the publisher will be able fulfill the terms of that 
subscription request."

In 3.5.1.

OLD:
"In a periodic subscription, the data included as part of an update 
corresponds to data that could have been read using a retrieval operation."

See above. Is there a difference between update and update record? If 
so, highlight it, please - Optional NEW:
"In a periodic subscription, the data included as part of an update 
record corresponds to data that could have been read using a retrieval 
operation."

(there are multiple occurrences)

In 3.5.2.

OLD:
"Therefore encoding rules for data in on-change updates will generally 
follow YANG-patch operation as specified in [RFC8072]."

NEW:
"Therefore, encoding rules for data in on-change updates will generally 
follow YANG-patch operation as specified in [RFC8072]."

In 3.5.2.

OLD:
"However a patch must be able to do more than just describe the delta 
from the previous state to the current state. As per Section 3.3, it 
must also be able to identify if transient changes have occurred on an 
object during a dampening period."

NEW:
"However, a patch must be able to do more than just describe the delta 
from the previous state to the current state. As per Section 3.3, it 
must also be able to identify, if transient changes have occurred on an 
object during a dampening period."

In 3.6.

xpath, Xpath and XPath are found in this section. More consistency 
cannot hurt.

In 3.7.

OLD:
"First it will be used as the initial "push-update" if there is a need 
to synchronize the receiver at the start of a new subscription."

NEW:
"First, it will be used as the initial "push-update", if there is a need 
to synchronize the receiver at the start of a new subscription."

In 4.3.2.

OLD:
"Where it is, the relevant "subscription-id" MUST be encoded as the 
first element within each "push-update" or "push-change-update"."

NEW:
"If present, "subscription-id" MUST be encoded as the first element 
within each "push-update" or "push-change-update"."

In 4.4.1.

OLD:
"The specific parameters to be returned in as part of the RPC error 
response depend on the specific transport that is used to manage the 
subscription."

NEW:
"The specific parameters to be returned as part of the RPC error 
response depend on the specific transport that is used to manage the 
subscription."

In 4.4.2.

The non-normative may is intentional here, correct? Also, rpc is also 
low caps here again - more consistency cannot hurt?
"This rpc error response may contain hints encapsulated within the 
yang-data structure "modify-subscription-error-datastore".

In 4.4.4.

OLD:
"This RPC is only applicable only for on-change subscriptions previously 
established using an "establish-subscription" RPC."

NEW:
"This RPC is only applicable for on-change subscriptions previously 
established using an "establish-subscription" RPC."

In 4.4.5.

Is this intended to be a guidance section? It seems to me that the use 
of RFC6470 might be a good enough basis to warrant a SHOULD somewhere?

Viele Grüße,

Henk

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 28 Aug 2018 17:46:44 +0000

Hi Qin,

thank you for your comments!  Replies inline, <ALEX>

--- Alex

> From: Netconf [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Monday, August 27, 2018 8:24 PM
> To: Kent Watsen <[email-masked]>; [email-masked]
> Subject: Re: [Netconf] Last Call on yang-push-17
> 

<ALEX> We should reference 8341, not 8342, as also Martin has pointed out.  It is true that this is about get and get-config operation, but the relevance is explained here:  " Each "push-update" and "push-change-update" MUST have access control
   applied.  This includes validating that read access is permitted for
   any new objects".  In other words, for a push update the same checks apply as for a get - the only difference really is that the get is on-demand whereas the push is subscribed.  
</ALEX>

> Also I think remote mirroring appears only once in the abstract, it will be
> great to add definition of remote mirroring, it is hard to understand at the
> first place.

<ALEX> Hmm.  It is true that mirroring is only mentioned once, in the abstract.  However, I am not sure this needs to explained further - the sentence clearly explains what this is about: "remote mirroring of configuration and operational state".   We could add "...   in a datastore to a client application" at the end, however, I am not sure this makes it really better (only longer)? </ALEX>

> Do we have mechanism specified for this?

<ALEX> Yes, and we have provided some updates to this section also per earlier comments by Tim to explain those mechanisms briefly.  It is also explained in the bulleted list below. </ALEX>
> 
> -Qin
> On 2018-08-14, 1:28 PM, "Netconf on behalf of Kent Watsen" <netconf-
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 28 Aug 2018 21:02:07 +0000

Hello Henk,

Thanks
--- Alex

> From: Netconf [mailto:[email-masked]] On Behalf Of Henk
> Birkholz
> Sent: Tuesday, August 28, 2018 5:49 AM
> To: [email-masked]
> after a thorough review of yang-push-17 I think it is in good shape and ready
> to progress.
> 
> It seems to me that "update record" and "update" are used synonymously in
> this document? If so, please add something like the following to the
<ALEX> ok </ALEX>

> "YANG-push subscriptions are defined using a YANG data model."

<ALEX> sure.  After too much writing, it is easy to get dizzy:-) </ALEX>

> completes assembly. As long as a dampening period is in effect, the Update
> Trigger functions the same way as with periodic subscriptions, using the
> dampening period as the periodic interval."
> 

<ALEX> Would rather not say that they are the same - because then there is the issue of start time / anchor time etc.  I think it is clear as is.  Of course, one could say, if changes continue to occur during dampening periods, the on-change subscription behaves like a periodic description, with the dampening period as the de-facto periodic interval.  However, I don't think this is needed for clarification and would rather leave it as-is.  
</ALEX>  

> consider these hints, will be accepted."
<ALEX>  I don't think the commas are needed (but in German they would be;-) </ALEX>

> "In case of a configured subscription, the subscription MAY be suspended by
> the publisher."
> 

<ALEX> Changed to: "In case of a configured subscription, the publisher MAY suspend the subscription." 
</ALEX>

> "access control rules" are rather surprisingly introduced here and then never
> mentioned again.
> 

<ALEX> well, it _is_ mentioned and explained in section 3.9.  To make it clearer what is meant here, rephrased the bullet item as follows: 
"Just before a change, or at the start of a dampening period, evaluate any filtering and any access control rules to ensure receiver is authorized to view all subscribed datastore nodes."
</ALEX>

> Same thing with "patch record" the term is only used in the context of the
> conceptual process and never again. Why is this not an update record? The
> relationship to RFC8072 is elaborated on in 3.5.2., but is surprising to be found
> here already.
> 

<ALEX> Changed as follows:
"Construct an update record, which takes the form of YANG patch record for going from A to B."
</ALEX>

> In 3.3.
> 
> OLD:
> "A publisher SHOULD reject a request for a subscription if it is unlikely that
> the publisher will be able fulfill the terms of that subscription request."
> 
> NEW:
> "A publisher SHOULD reject a request for a subscription, if it is unlikely that
> the publisher will be able fulfill the terms of that subscription request."

<ALEX> I think the lack of a comma is actually correct. </ALEX>
> See above. Is there a difference between update and update record? If so,
> highlight it, please - Optional NEW:
> "In a periodic subscription, the data included as part of an update record

<ALEX> Added the caveat in the terminology section, but changed it to update record here to make it more explicit that yes, indeed, this is what we are talking about.  </ALEX>

> 
> In 3.5.2.
> 
> OLD:
> "Therefore encoding rules for data in on-change updates will generally follow
> YANG-patch operation as specified in [RFC8072]."
> 
> NEW:

<ALEX> ok </ALEX>

> In 3.5.2.
> 
> OLD:
> "However a patch must be able to do more than just describe the delta from
> the previous state to the current state. As per Section 3.3, it must also be
> able to identify if transient changes have occurred on an object during a
> dampening period."
> 
> NEW:
> "However, a patch must be able to do more than just describe the delta from
> the previous state to the current state. As per Section 3.3, it must also be
> able to identify, if transient changes have occurred on an object during a
> dampening period."

<ALEX> Added the comma after "However".  Left the non-comma before "if" but changed "if" to "whether"
</ALEX>

> 
> In 3.6.
> 
> xpath, Xpath and XPath are found in this section. More consistency cannot
> hurt.
> 

<ALEX>, well, xpath refers to the type, whether XPath refers to XPath.  (But got rid of the "Xpath"s, per someone else's earlier comment. </ALEX>

> In 3.7.
> 
> OLD:
> "First it will be used as the initial "push-update" if there is a need to
> synchronize the receiver at the start of a new subscription."
> 
> NEW:
> "First, it will be used as the initial "push-update", if there is a need to
> synchronize the receiver at the start of a new subscription."
> 

<ALEX> Sentence was already changed due to an earlier comment.  It now reads as follows:
"First, it MUST be used as the initial "push-update" if there is a need to synchronize the receiver at the start of a new subscription.  "
</ALEX>

> In 4.3.2.
> 
> OLD:
> "Where it is, the relevant "subscription-id" MUST be encoded as the first
> element within each "push-update" or "push-change-update"."
> 
> NEW:
> "If present, "subscription-id" MUST be encoded as the first element within
> each "push-update" or "push-change-update"."
> 

<ALEX> This has been changed to (also per previous comment) to 
"An "identifier" (that identifies the subscription) MUST be transported along with the subscribed contents.  
			This allows a receiver to differentiate which subscription resulted in a particular push. "
</ALEX>

> In 4.4.1.
> 
> OLD:
> "The specific parameters to be returned in as part of the RPC error response
> depend on the specific transport that is used to manage the subscription."
> 
> NEW:
> "The specific parameters to be returned as part of the RPC error response
> depend on the specific transport that is used to manage the subscription."

<ALEX> done, thank you </ALEX>
> 
> In 4.4.2.
> 
> The non-normative may is intentional here, correct? Also, rpc is also low caps
> here again - more consistency cannot hurt?
> "This rpc error response may contain hints encapsulated within the yang-data
> structure "modify-subscription-error-datastore".
> 

<ALEX> Changed rpc --> RPC.   Also, the text has been changed (may --> SHOULD), also per earlier comments. </ALEX>

> established using an "establish-subscription" RPC."

<ALEX> Changed to " This RPC is supported only for on-change subscriptions previously established using an "establish-subscription" RPC.", also in response to earlier request </ALEX>

> In 4.4.5.
> 
> Is this intended to be a guidance section? It seems to me that the use of
> RFC6470 might be a good enough basis to warrant a SHOULD somewhere?
> 

<ALEX> the text has been updated, also per earlier comments by Martin.  
Thanks again for your valuable comments!
--- Alex
</ALEX>

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 29 Aug 2018 00:23:21 +0000

Hi Reshad,

thank you for your comments!

Please find responses inline, <ALEX>

--- Alex

> From: Netconf [mailto:[email-masked]] On Behalf Of Reshad
> Rahman (rrahman)
> Sent: Monday, August 27, 2018 7:18 PM
> I believe yang-push-17 is in very good shape and is ready to progress to the
> next step. Here are my nits/comments/questions, nothing major:
> 

<ALEX> updated
</ALEX>

> - Abstract mentions "remote mirroring", should we really assume that these
> new capabilities all depend on "remote mirroring" of state?

<ALEX> The text states that this "enables new capabilities based on the remote mirroring of configuration and operational state".  There may be other capabilities as well.  From that perspective I don't think this is controversial.  That said, you are the second person who takes issue with remote mirroring, which makes me wonder if the sentence should be rephrased.  How about: " Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state."
</ALEX>

> - In Section 2 "Definitions and acronyms", there's mention that the
> terminology defined in RFCs  7950, 8341 and 8342 is used. We should also
> mention the subscribed-notifications draft since terminology such as
> subscribers, receivers etc is defined in that draft.

<ALEX> Thank you, updated
</ALEX>

> datastore updates that are specified..."

<ALEX> I believe that "is" is correct, because it refers to the mechanism, not to the updates (and it is one mechanism, not multiple) </ALEX>

> - Section 3 should be "a solution that provides a subscription service"

<ALEX> thank you, updated </ALEX>

> - Section 3.1 "additional parameters such as" implies there are more
> parameters. I believe there aren't more parameters? If there, add a a
> reference to the proper section(s)?

<ALEX> changed "such as" to "that include" </ALEX>

> - Section 3.1 "... to exhaust of resources" should be "to exhaust resources"

<ALEX> noted, changed </ALEX>

> - Section 3.1 "specify the interval which must pass before successive",

<ALEX> I think "must" is correct, since we cannot impose requirements on an interval.  However, to avoid ambiguities, changing "which must pass" to "which has to pass" </ALEX>

> - Section 3.1 (Page6), change "you might only send when an object is created
> or deleted" to "the publisher might only send notifications when an object is
> created or deleted"?

<ALEX> Changed to "might only send an update when ..." </ALEX>

> "allow receivers to receive updates"?

<ALEX> changed </ALEX>

<ALEX> ok </ALEX>

> - Section 3.4 2nd paragraph "publisher notifies receivers immediately and
> reliably whenever...", is it the receivers which are notified in such a situation
> or is it the subscriber?

<ALEX> It is the receiver, as is stated in the text </ALEX>

> - Section 3.5.2 s/datstore/datastore/

<ALEX> corrected </ALEX>

> - Section 3.5.2 2nd paragraph, text uses past tense "was created", "was
> deleted", should the present be used instead?

<ALEX> I think "past" is fine.  This concerns that an update has taken place.  There may be dampening which causes updates to reported that have already occurred in the past.  </ALEX>

> - Section 3.5.2 3rd paragraph, "However a patch must be able...", should that

<ALEX> We call it "patch" throughout this section.  I think it is clear what is meant here.  </ALEX>

<ALEX> ok </ALEX>

<ALEX> ok </ALEX>

> - Section 3.7 4th paragraph, sentence "These new "push-update" and "push-
> change-update" are encoded..." doesn't read well. But I'm not sure how to
> make it better, maybe add "events" before "are encoded"?

<ALEX> rephrased as follows: " "Push-update" and "push-change-update" are encoded and placed within notification messages, and ultimately queued for egress over the specified transport. " </ALEX>

> is mentioned, add a reference?

<ALEX> Don't think this is needed.  This obviously discusses the data model, where this is defined.  </ALEX>

<ALEX> ok </ALEX>

<ALEX> ok </ALEX>

<ALEX> ok </ALEX> 

> - Section 4.4.1 Figure 10. There seems to be a mistake in the XML example for
> the error response, we have </error-message> instead of </error-app-tag>

<ALEX> Example has been corrected per Martin's comment </ALEX> 

<ALEX> ok </ALEX>

<ALEX> ok </ALEX>

> - YANG model P39, leaf nodes kilobytes-limit and kilobytes-estimate, why
> not use units "kilobyte" and rename these 2 leaf nodes to limit and estimate?

<ALEX> well, the name indicates the unit, guess it's a matter of taste, leaving it unchanged (unless you feel strongly about it). 
Thanks again for your comments!
--- Alex
 </ALEX>

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 29 Aug 2018 00:41:54 +0000

Hi Mahesh,

I changed the text as requested.  I moved the first item on the list into parantheses as a note before the list.

-- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Monday, August 27, 2018 3:45 PM
To: [email-masked]
Subject: Re: [Netconf] Last Call on yang-push-17

The document follows the template defined in OPS-Dir wiki here<https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>, but there is a reference in the template that needs to be updated.

Thanks.

On Aug 14, 2018, at 10:28 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Kent (and Mahesh)

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 29 Aug 2018 21:02:52 +0000

Hi Alex,

Good on all fronts.

Regards,
Reshad.

On 2018-08-28, 8:23 PM, "Alexander Clemm" <[email-masked]> wrote:

    Hi Reshad,

    
    --- Alex

    <ALEX> updated
    </ALEX>

    

    

    

    

    

    
    <ALEX> changed </ALEX>

    <ALEX> ok </ALEX>

    
    
    <ALEX> corrected </ALEX>

    

    
    <ALEX> ok </ALEX>

    <ALEX> ok </ALEX>

    

    
    <ALEX> ok </ALEX>

    <ALEX> ok </ALEX>

    <ALEX> ok </ALEX> 

    
    
    <ALEX> ok </ALEX>

    <ALEX> ok </ALEX>