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

From: Qin Wu <[email-masked]>
Date: Thu, 11 Oct 2018 02:24:38 +0000

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 11 Oct 2018 21:01:35 +0000

Hi Qin,

Thanks for the review, please see inline.

On 2018-10-10, 10:25 PM, "Netconf on behalf of Qin Wu" <[email-masked] on behalf of [email-masked]> 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...."    
    
    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:
    
    "
<RR> Ack, you basically moved the part on POST right after the RPC and before we talk about GET.

    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.

    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.
    
    "
    
    "
    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.
    
    5.Section 3.4
    "
    
    "
    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). 

Regards,
Reshad.

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

---

From: Qin Wu <[email-masked]>
Date: Fri, 12 Oct 2018 01:02:30 +0000

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

Hi Qin,

    Hi,
 
[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:
    
    "

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

    3. Section 3.2

[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
    
    "
    
    "
    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
    "
    
    "
    confused.

[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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 12 Oct 2018 19:41:21 +0000

Hi Qin,

On 2018-10-11, 9:02 PM, "Qin Wu" <[email-masked]> wrote:

    -----邮件原件-----
    发件人: Reshad Rahman (rrahman) [mailto:[email-masked]] 
    发送时间: 2018年10月12日 5:02
    收件人: Qin Wu; [email-masked]
    主题: Re: [Netconf] WGLC on restconf-notif-08
    
    Hi Qin,

    
        Hi,

        "
    
<RR2> Ack.
    
        3. Section 3.2
    
    [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
        
        "
        
        "
        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
        "
        
        "
        confused.
    
    [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

---

From: Qin Wu <[email-masked]>
Date: Mon, 15 Oct 2018 02:26:15 +0000

-----邮件原件-----
发件人: Reshad Rahman (rrahman) [mailto:[email-masked]] 
发送时间: 2018年10月13日 3:41
收件人: Qin Wu; [email-masked]
主题: Re: [Netconf] WGLC on restconf-notif-08

Hi Qin,

    -----邮件原件-----
    发件人: Reshad Rahman (rrahman) [mailto:[email-masked]] 
    发送时间: 2018年10月12日 5:02
    收件人: Qin Wu; [email-masked]
    主题: Re: [Netconf] WGLC on restconf-notif-08
    
    Hi Qin,

    
        Hi,

        "
    
    [Qin2]: Thanks.

        4.Section 3.3
        
        "
        
        "
        
        "
    [Qin2]: Clarification makes sense, thanks.

        5.Section 3.4
        "
        
        "
        confused.

[Qin2]: I am clear now, Please make text clear as well. Thanks for clarification.
Regards,
Reshad.
    
    Regards,
    Reshad.

        -Qin