Re: [netconf] Adam Roach's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 17 May 2019 02:27 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 D874512033D; Thu, 16 May 2019 19:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 header.b=NYExRwE+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JMakpVOY
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 UWSU8goO0vPC; Thu, 16 May 2019 19:27:15 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056AA12014E; Thu, 16 May 2019 19:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14110; q=dns/txt; s=iport; t=1558060035; x=1559269635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hQtmKu10qh8Z41j/cDPGGODMnkPZIekJeichfS2YJTo=; b=NYExRwE+VGH0BFU/+liEuKl4IjnReyaU0G6w5znjmioDlTXn/xewmF9g EtQ/LDY8t6inPQIoE3vzSFZ2MN9WuUJJ3aZXkBzoFbh6zGOgxtwkk2jyq bD0JqNWU81qdKbHGoXFjIaMC65/6YkDRWWkrmuDOtgUzuIPJMufmTT8uT 0=;
IronPort-PHdr: 9a23:QqUqyBJNU3St3wFsJ9mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXFfhJf7vZioSF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BIAADjGt5c/5xdJa1bCRwBAQEEAQEHBAEBgVEHAQELAYE9JAUnA2lVIAQLKAqECINHA4RSiiKCV5cngS4UgRADVAkBAQEMAQEYCwoCAQGDekYCF4IXIzQJDgEDAQEEAQECAQRtHAyFSwEBAQIBAQEQEREMAQEsBAcBDwIBCBoCCRYHAgICJQsVEAIEAQ0BBCKCNUsBgWoDDg8BDqA0AoE1iF9xgS+CeQEBBYFGQYJ/GIIPAwaBCygBi08XgUA/gREnH4JMPoJhAQEBAgGBKgEICgEJFgcQIQKCUDKCJosZCwoOgjOGb5JKZQkCggmGK4Q+hDSDVRuCG4ZSBY0cjEiBJYVBjkcCBAIEBQIOAQEFgU84KT1YEQhwFTsqAYJBgg83gziFFIU/cgEOgRqMCYEiAYEgAQE
X-IronPort-AV: E=Sophos;i="5.60,478,1549929600"; d="scan'208";a="559049836"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 May 2019 02:27:13 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x4H2RDia018821 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 May 2019 02:27:13 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 21:27:13 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 22:27:11 -0400
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 16 May 2019 22:27:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hQtmKu10qh8Z41j/cDPGGODMnkPZIekJeichfS2YJTo=; b=JMakpVOYnyrEaGBxljkktZdzpHKs4Eylxtdhj75Ec4txT9R4rSDy0Uy6pvkURxKq+mlqsRO93kd7VGHsX8XUQbT/xHKG6gok06ApsPowAG8ne+f9ZGQlDepvecK4M03AZnC4qyIO1Ve5yGAxs/zC2a+ZjL/JsaW+luXIE9JG2U8=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2348.namprd11.prod.outlook.com (10.173.174.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Fri, 17 May 2019 02:27:10 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1900.010; Fri, 17 May 2019 02:27:10 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-netconf-restconf-notif@ietf.org" <draft-ietf-netconf-restconf-notif@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Adam Roach's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
Thread-Index: AQHVCu60QWyOYQqwSEOksNKzIOWLIqZuVagA
Date: Fri, 17 May 2019 02:27:09 +0000
Message-ID: <D7C97D28-DC47-40CE-B761-92497A0AAFA4@cisco.com>
References: <155790481851.17474.3456985672733157831.idtracker@ietfa.amsl.com>
In-Reply-To: <155790481851.17474.3456985672733157831.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com;
x-originating-ip: [173.38.117.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bf24905c-8de7-4646-56ae-08d6da6f2a1e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2348;
x-ms-traffictypediagnostic: DM5PR1101MB2348:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM5PR1101MB2348AB7FAE12CCBD798327A5AB0B0@DM5PR1101MB2348.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0040126723
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(366004)(396003)(136003)(51914003)(189003)(199004)(8936002)(6512007)(6306002)(11346002)(2616005)(36756003)(64756008)(76116006)(26005)(5660300002)(68736007)(476003)(82746002)(91956017)(86362001)(71200400001)(71190400001)(66446008)(14454004)(486006)(66946007)(83716004)(66476007)(66556008)(73956011)(2906002)(3846002)(6116002)(4326008)(8676002)(33656002)(6246003)(66066001)(81156014)(478600001)(81166006)(14444005)(966005)(256004)(58126008)(305945005)(76176011)(99286004)(316002)(102836004)(6486002)(229853002)(6506007)(6436002)(53936002)(25786009)(54906003)(446003)(110136005)(7736002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2348; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: v/p0SwIwvx3u22v6eyzPRCi+RhutYx6rWgSzUVWA7WZZ9MJIFHt4zUNsQ42pYnL2H0DN++jSoXqsNRprLTSWtghZDfZn5yINtrAb54cRADKCxkq/0yUCnLCaqoocNt792eedXG6ly8uI/9LxgMSOu09K2dbpU4V7nvftT4/gShnfN5T+STDRaRgVGpxImTOE3ZaYAlhr9qsHJO0Mh3Poh6DeNjtd43Q6xP0o41CiviAK2YSsqecd4EnZWVs2tzbJOAeab5qkp4Lgut2OLZ1qxIzrBLsl8aGOTa4mytvG5HK+MzohMJdzVqaVAJi6W2sQmkUcVltKDBc1YqsOvF5R8yTzM+WBXdH6V6DiuqG6t322jyKP3q0Jg9u9ZQPGnpYZy3fAi4cvs5LAhD2OB3dI8AUR5knoMFhXJoanBmDcxXQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <DF9A2A70C5DF43498CA3CCAA0CD60577@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bf24905c-8de7-4646-56ae-08d6da6f2a1e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 02:27:10.0969 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2348
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0xDquMejwq9Ob8682-fPC2_3GyY>
Subject: Re: [netconf] Adam Roach's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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: Fri, 17 May 2019 02:27:18 -0000
Hi, Thanks for the review, please see inline. On 2019-05-15, 3:20 AM, "netconf on behalf of Adam Roach via Datatracker" <netconf-bounces@ietf.org on behalf of noreply@ietf.org> wrote: Adam Roach has entered the following ballot position for draft-ietf-netconf-restconf-notif-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for all the work that the authors and other contributors have put into this document. I have two comments that need to be addressed before publication, but they should both be very easy to fix. --------------------------------------------------------------------------- §3.3: > If a publisher fails to serve the RPC request for one of the reasons > indicated in [I-D.draft-ietf-netconf-subscribed-notifications] > Section 2.4.6 or [I-D.ietf-netconf-yang-push] Appendix A, this will > be indicated by "406" status code transported in the HTTP response. This really isn't what 406 means. 406 means "you sent one or more of the 'Accept', 'Accept-Charset', 'Accept-Encoding', or 'Accept-Language' header fields, and I can't generate a response that satisfies what you've asked for." For some of the errors listed in the two cited sections, there is a reasonable semantic mapping onto existing HTTP response codes; e.g. the "no-such-subscription" errors could all reasonably map on to HTTP 404. I'll note that RFC 8040 section 7 performs exactly this kind of mapping, so the approach seems to be consistent with the way that RESTCONF has elected to use HTTP response codes. In fact, this document already maps from the cited errors to error tags already, and that table maps from error-tag to HTTP response codes, so fixing this should be the relatively straightforward exercise of updaing the tables in this section to also include the HTTP response code that RFC 8040 maps to the indicated error-tag. For example: error identity uses error-tag HTTP Response ---------------------- -------------- ------------- dscp-unavailable invalid-value 400 encoding-unsupported invalid-value 400 filter-unsupported invalid-value 400 insufficient-resources resource-denied 409 no-such-subscription invalid-value 404 replay-unsupported operation-not-supported 501 error identity uses error-tag HTTP Response ---------------------- -------------- ------------- cant-exclude operation-not-supported 501 datastore-not-subscribable invalid-value 400 no-such-subscription-resync invalid-value 404 on-change-unsupported operation-not-supported 501 on-change-sync-unsupported operation-not-supported 501 period-unsupported invalid-value 400 update-too-big too-big 400 sync-too-big too-big 400 unchanging-selection operation-failed 500 However you choose to address this, if the error isn't related to any of the four header fields I mention above, then you can't specify the use of a 406. <RR> Thank you for suggesting status codes for the different errors, much appreciated. I agree that 406 is not appropriate. Regarding 400, my understanding is that it is for invalid syntax, so for errors such as dscp-unavailable or encoding-unsupported, would 409 be more appropriate than 400? --------------------------------------------------------------------------- §3.4: This section is unclear about how Server-Sent Events are to be used (in particular, they don't say anything about event type to be used). Based on the one example in Appendix A that shows SSE syntax, I'm assuming you probably do not intend to use SSE "event type" fields to distinguish between events in any way. This would mean that you need to specify that all SSE messages are sent with an event type of "message," which the server may omit (as it is the default specified in the Server-Side Events specification). This means that clients will need to accept both: data: { data: "ietf-restconf:notification" : { data: "eventTime": "2007-09-01T10:00:00Z", data: "ietf-subscribed-notifications:subscription-modified": { data: "id": "39", data: "uri": "https://example.com/restconf/subscriptions/22" data: "stream-xpath-filter": "/example-module:foo", data: "stream": { data: "ietf-netconf-subscribed-notifications" : "NETCONF" data: } data: } data: } data: } ...and... event: message data: { data: "ietf-restconf:notification" : { data: "eventTime": "2007-09-01T10:00:00Z", data: "ietf-subscribed-notifications:subscription-modified": { data: "id": "39", data: "uri": "https://example.com/restconf/subscriptions/22" data: "stream-xpath-filter": "/example-module:foo", data: "stream": { data: "ietf-netconf-subscribed-notifications" : "NETCONF" data: } data: } data: } data: } It may be helpful to incorporate the SSE syntax into all of the notification examples in Appendix A (that is, all of the examples in A.2 and A.3). I would recommend a mix of examples with and without "event: message". <RR> Andy Bierman (one of the co-authors) mentioned that RESTCONF does not define any values for "event" and pointed us to this text from RFC8040 P72 A RESTCONF server SHOULD NOT send the "event" or "id" fields, as there are no meaningful values that could be used for them that would not be redundant to the contents of the notification itself. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General comment: It's a bit unclear about what the normative relationship between a Server-Sent Events connection and a subscription is intended to be. For example: if I send an RPC command to create a subscription, and then make two different SSE connections to the resulting URL, will they both receive events associated with that subscription? If so, does a TLS heartbeat failure on one of them cause the entire subscription to go away? (If not, what happens?) <RR> The resource created via the establish-subscription is for 1 subscription. There can only be 1 GET on the URI at the same time, this does not seem to be explicitly stated anywhere, so probably a good idea to add text to that effect. If I have only one connection related to a subscription, and I close the TCP connection, does that necessarily make the subscription go away? What if I set up a new TCP connection right away after closing the first one? Will that work? <RR> The subscription will not go away when the TCP connection is closed. As mentioned at the end of 3.4, the subscription goes away on receipt of delete-subscription/kill-subscription RPCs or on loss of TLS heartbeat. If a client does a GET after closing the first GET, yes this is supposed to work. What if I use RPC to set up a new subscription, and then wait a few minutes before connecting to the subscription URL? <RR> That is also supposed to work as long as the subscription wasn't terminated as per section 3.4. I don't think you need to answer all of these corner cases per se (although it would be nice), but minimally a couple of statements that clearly spell out the relationship between subscriptions and the connections used to deliver related events would help implementors figure out the answers to these questions. --------------------------------------------------------------------------- §2: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. Please use the boilerplate specified by RFC 8174. <RR> Will do. --------------------------------------------------------------------------- §3.1: > As stated in Section 2.1 of [RFC8040], a subscriber MUST establish > the HTTP session over TLS [RFC5246] in order to secure the content in > transit. Is the intention here to restrict clients to TLS 1.2? If not, please cite RFC 8446 instead of RFC 5246. If so, please add text that explains why. (This comment also applies to section 9) <RR> Will update to RFC8446. --------------------------------------------------------------------------- §3.1: > Loss of the heartbeat MUST result in any subscription related TCP nit: "...subcription-related..." <RR> Will change to subscription-related. Regards, Reshad. _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf
- [netconf] Adam Roach's Discuss on draft-ietf-netc… Adam Roach via Datatracker
- Re: [netconf] Adam Roach's Discuss on draft-ietf-… Reshad Rahman (rrahman)
- Re: [netconf] Adam Roach's Discuss on draft-ietf-… Adam Roach