Re: [Netconf] WGLC on restconf-notif-08

-----邮件原件-----
发件人: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] 
发送时间: 2018年10月12日 5:02
收件人: Qin Wu; netconf@ietf.org
主题: Re: [Netconf] WGLC on restconf-notif-08

Hi Qin,

Thanks for the review, please see inline.

On 2018-10-10, 10:25 PM, "Netconf on behalf of Qin Wu" <netconf-bounces@ietf.org on behalf of bill.wu@huawei.com> wrote:

    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?
<RR> This just means RPCs (which are done with POSTs). New proposed text:
"... in this way via RPCs, which are done with RESTCONF POSTs, defined within...."    

[Qin]: make sense. Thanks.
    2.section 3
    I think this section explain why POST is used instead of GET for URI retieval.
<RR> Yes, the POST is for the establish-subscription RPC and the URI is in the reply. 
    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.  
    "
<RR> Ack, you basically moved the part on POST right after the RPC and before we talk about GET.

[Qin]: Correct, but more clear and logical.

    3. Section 3.2
    Is there any reason not reuse streams defined in ietf-restconf-monitoring.yang in [RFC6520]?
<RR> Because we're building on top of SN draft.

[Qin]: I am pathetic on streams defined in ietf-restconf-monitoring.yang, Is there any limitation of those streams?
is there any case we can fall back to rely on streams defined in ietf-restconf-monitoring.yang?

    4.Section 3.3
    Why JSON encoding is emphasized? what about XML encoding?
<RR> XML encoding is supported (since this is RESTCONF), I think this doc started with JSON because netconf-notif has XML.

    "
       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?
<RR> RFC8040 specifies error-path in rpc-error, what this text says is that error-path does not need to be included.
[Qin]: what is not clear to me is the second half part
"
subscription errors are generally not associated
       with nodes in the datastore but with the choice of RPC input
       parameters.
"
Can you give an example to explain this?

    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.
<RR> I don’t think this is a contradiction. You can have multiple RPCs on single transport session (by not closing the transport session after each RPC). With HTTP2 streams, you can have multiple notification messages from different subscriptions on same transport session (but different streams). 

[Qin]: I thought connection and transport session is 1:1 relation, it seems you believe multiple connection can be carried in one single transport session, wrong?

Regards,
Reshad.

    -Qin

    _______________________________________________
    Netconf mailing list
    Netconf@ietf.org
    https://www.ietf.org/mailman/listinfo/netconf