[Netconf] WGLC on restconf-notif-08

[Qin Wu <[e-mail]>]

Hi,
I have read the latest version of restconf-notif-08 and have the following comments:
1. Section 3
"  Subscribing to event
   streams is accomplished in this way via a RESTCONF POST into RPCs
   defined within [I-D.draft-ietf-netconf-subscribed-notifications]
   Section 2.4.
"
hard to understand this sentence, what do we mean "via RESTCONF POST into RPCs"?
in which way?


2.section 3
I think this section explain why POST is used instead of GET for URI retieval.
Suggest the following change:

"
As described in [RFC8040] Section 6.3, a GET needs to be made against
   a specific URI on the publisher.  Subscribers cannot pre-determine
   the URI against which a subscription might exist on a publisher, as
   the URI will only exist after the "establish-subscription" RPC has
   been accepted. Therefore The POST for the "establish-subscription" RPC    replaces the
   GET request for the "location" leaf which is used in [RFC8040] to
   obtain the URI. When The subscription URI is determined and sent as
   part of the response to the "establish-subscription" RPC, and a
   subsequent GET to this URI will be done in order to start the flow of
   notification messages back to the subscriber.  A subscription does
   not move to the active state as per Section 2.4.1. of
   [I-D.draft-ietf-netconf-subscribed-notifications] until the GET is
   received.  
"
3. Section 3.2
Is there any reason not reuse streams defined in ietf-restconf-monitoring.yang in [RFC6520]?
4.Section 3.3
Why JSON encoding is emphasized? what about XML encoding?

"
   Note that "error-path" does not need to be included with the "rpc-
   error" element, as subscription errors are generally not associated
   with nodes in the datastore but with the choice of RPC input
   parameters.

"
not sure I understand this, is this difference between NETCONF and RESTCONF?
RESTCONF server doesn't support NETCONF protocol or datastore?

5.Section 3.4
"
In addition to an RPC response for a "modify-subscription" RPC
      traveling over (a), a "subscription-modified" state change
      notification must be sent within (b). 
"
Does this contradict with the statement in subscrbed notification draft
"
unlike [RFC5277], this document enables a single transport session
      to intermix notification messages and RPCs for different
      subscriptions.

"
confused.


-Qin