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

Hi Qin,

On 2018-10-11, 9:02 PM, "Qin Wu" <bill.wu@huawei.com> wrote:

    -----邮件原件-----
    发件人: 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.
<RR2> Ack.

        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?
<RR2> I don't see any case why we'd need to fall back to the RC stream model.

        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?
<RR2> The text is saying that if a subscription fails, it is generally because of an issue with input parameters (e.g. polling interval too aggressive, dscp not supported) and not because of an error with a specific data node. From definition of error-path in RFC8040, it's an instance-identifier so it points to a specific node in the datastore.
           leaf error-path {
             type instance-identifier;
             description
               "The YANG instance identifier associated
                with the error node.";
           } 
I can remove the second part to try to make this text clearer, I can also add a reference to 8040 for error-path:
        "
           Note that "error-path" [RFC8040] does not need to be included with the "rpc-
           error" element, as subscription errors are generally associated with the choice of RPC input
           parameters.

        "

        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?
<RR2> No, I'm referring to logical connections (Section 3.4) which can e.g. be a HTTP2 stream. 

Regards,
Reshad.

    Regards,
    Reshad.

        -Qin

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