IETF Logo Mail Archive

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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Thu, 11 October 2018 14:52 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B7A130DD3 for <netconf@ietfa.amsl.com>; Thu, 11 Oct 2018 07:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.956
X-Spam-Level:
X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dCpl0CPWcNe for <netconf@ietfa.amsl.com>; Thu, 11 Oct 2018 07:52:18 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987F8130E7C for <netconf@ietf.org>; Thu, 11 Oct 2018 07:52:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3030; q=dns/txt; s=iport; t=1539269536; x=1540479136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OSVcr+gQOY3E7lswocA3gFuH5rGrajpz4ZGmc97MLbo=; b=dqODxhqNotdH5aVAfqXOEb/1DG/jifBaUJUjBdDxOn+OiXxyLCC0r7bB 7p3yjhfy4CpyOgOMCwL5Uo+iNxzrHYoL+k6uZWYPMjCHXXM1eJnZVcAbF lcv128kJSihaTmdj1xf/EcFbyZ56Jk3Qu8PgrROgY02LLLsNQ5TYHPyaR g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAAAmY79b/4ENJK1iGQEBAQEBAQEBAQEBAQcBAQEBAQGBUgMBAQEBAQsBggNmfygKg2uWNCWXAIF6CwEBLIRAAheEPiE1DA0BAwEBAgEBAm0ohTkBAQEBAgEjEUUQAgEIDgoCAgkdAgICMBUQAgQOBYMgAYF5CKYbgS6Ed4RkgQuKOheBQT+BEicME4JMhF4BATUjgkcxgiYCnhAJApBSF5ARlWsCERSBJR8DMyeBLnAVZQGCQZBUAW+BFokNgR8BgR4BAQ
X-IronPort-AV: E=Sophos;i="5.54,368,1534809600"; d="scan'208";a="184815214"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 14:52:15 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9BEqFtR014358 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Oct 2018 14:52:15 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Oct 2018 09:52:14 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Thu, 11 Oct 2018 09:52:14 -0500
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] WGLC on restconf-notif-08
Thread-Index: AQHUXC8dqc/ZdIehM0Ol7lZ9+zKBhqUYuN6AgAAzPQCAABNOAIABCG2AgAA0jIA=
Date: Thu, 11 Oct 2018 14:52:14 +0000
Message-ID: <D13E18F0-F70F-4237-A916-0876FE1215CA@cisco.com>
References: <20181010.134515.758050607192527205.mbj@tail-f.com> <C5B41C06-F491-417B-A5BB-8448C6A6DF28@cisco.com> <45636281-5A9E-4060-AB37-04FEBCF7A61D@cisco.com> <20181011.094409.63387308227444431.mbj@tail-f.com>
In-Reply-To: <20181011.094409.63387308227444431.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.54]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B812A0F1A9DD6C4AA4551DBF62A74964@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/OcjNvh3TjsJxMwQ7CxtdaI5R8W8>
Subject: Re: [Netconf] WGLC on restconf-notif-08
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Oct 2018 14:52:20 -0000

Hi,

On 2018-10-11, 3:44 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

    "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
    > Inline.
    > 
    > On 2018-10-10, 2:49 PM, "Netconf on behalf of Reshad Rahman (rrahman)"
    > <netconf-bounces@ietf.org on behalf of rrahman@cisco.com> wrote:
    > 
    >     Thanks for the review, inline.
    >     
    >     On 2018-10-10, 7:45 AM, "Netconf on behalf of Martin Bjorklund"
    >     <netconf-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:
    >     
    > <Trimmed>
    >         
    >         o  Section 3.4
    >         
    >           The text says:
    >         
    >            An HTTP GET is then sent on a separate logical connection (b) to
    >            the
    >            URI on the publisher.
    >         
    >           I think that is also ok if the GET is sent on (a) - in the case that
    >           you don't care about being able to modify the subscription.  This
    >           should be clarified.
    >      <RR> Yes that also works, will add some text.
    > <RR2> That would also prevent the subscriber from deleting the
    > subscription. So I don't think this should be allowed, don't see the
    > benefit.
    
    The subscriber can simply close the connection to terminate.  I
    suspect this is what most implementations will do anyway.
<RR3>  Assuming it's 1 subscription per connection, yes.
   
    >           Also, "modify-subscription" may be sent on some other session.
    >     <RR> As long as from same subscriber I assume. Do we care about NAT
    >     scenarios?
    >         
    > <RR2> Why allow for modify-subscription on another session, is this
    > not an unnecessary complication?
    
    See my previous mail.  I think the current restriction is a
    complication.  Note that there are no sessions in RESTCONF.  It is
    true that the underlying HTTP connection can be kept, but this is just
    an optimization.  We can't make the RESTCONF protocol behavior depend
    on this.
<RR3> Current restriction is a complication because the publisher would have extra check?    

Regards,
Reshad.

    /martin

v2.23.0 | Report a Bug | By Email