Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs protocol design team
Andy Bierman <andy@yumaworks.com> Fri, 18 September 2015 16:52 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: i2rs-proto-dt@ietfa.amsl.com
Delivered-To: i2rs-proto-dt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82161A017C for <i2rs-proto-dt@ietfa.amsl.com>; Fri, 18 Sep 2015 09:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 diz0ENP-4Nfy for <i2rs-proto-dt@ietfa.amsl.com>; Fri, 18 Sep 2015 09:52:27 -0700 (PDT)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045D41A7021 for <i2rs-proto-dt@ietf.org>; Fri, 18 Sep 2015 09:52:27 -0700 (PDT)
Received: by lbpo4 with SMTP id o4so28166651lbp.2 for <i2rs-proto-dt@ietf.org>; Fri, 18 Sep 2015 09:52:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O7/VSHRfCVSIb51cqPDx4HAb2lRKgr6OXZq83AzCLC8=; b=ZDw44sb94VmNvWa1WnpvE2VMXhONEK42PYIIqD6k9SnqA30p4WnNIs0i+HlD8z8koh DIXTNVOgYy7yNebRNuJogfPYBZcq4GaNxjqE2VLHucIeVyzPOS94bQt9AVF0dVw2FXjF HD84X2tyjDQvyfksuAHFmzJyllNFkvYBHjkq1gouOPSrkumWw9RZYjm0vLJYQ70b2OSG TyjFnTBDXzLXWAGM5oKOb1smQfPBBmZNY1YZ2pEDHs/rWgvYtf1grb9VakfYhfE6cDiV GOecyIysnFVaqr40+QEsY2xMvq2VssknDfJAsIPZCEAtY8ASgOOPoLGsQ7umj6PtyhMq cBAg==
X-Gm-Message-State: ALoCoQmbdnNC/XdH4QgE6w9uRFJ69LaTtTrk5kwf9Hl0oybgW9JUEjR2CCT+QjdivggHkswYmUWs
MIME-Version: 1.0
X-Received: by 10.112.13.40 with SMTP id e8mr3602155lbc.82.1442595145171; Fri, 18 Sep 2015 09:52:25 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Fri, 18 Sep 2015 09:52:25 -0700 (PDT)
In-Reply-To: <00ac01d0f229$8fc556c0$af500440$@ndzh.com>
References: <188578508.8602.1442583821396.JavaMail.nobody@jva2tc215.webex.com> <000601d0f218$8b330d20$a1992760$@ndzh.com> <CABCOCHR080tt3jyt2w-di+CMdAvhFE_ga+MpQ3=Tr3GSsJETiQ@mail.gmail.com> <00ac01d0f229$8fc556c0$af500440$@ndzh.com>
Date: Fri, 18 Sep 2015 09:52:25 -0700
Message-ID: <CABCOCHR0kmarpW0SmKdO86xkDCS7ruZzGDY9KsFNStvawmXFxg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="001a11c3a1e42ee96b0520085b3b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/HGu1VjwxwTrdMa3LkJxoPKFM09w>
Cc: i2rs-proto-dt@ietf.org
Subject: Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs protocol design team
X-BeenThere: i2rs-proto-dt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: I2RS protocol design team <i2rs-proto-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs-proto-dt/>
List-Post: <mailto:i2rs-proto-dt@ietf.org>
List-Help: <mailto:i2rs-proto-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2015 16:52:30 -0000
Hi, Here are the notes I have for the draft Kent and I were starting. It is probably controversial, but perhaps useful for discussing some details. On document structure: ------------------------------- 1) Intro 2) Definition of intended config, applied config and derived state for NETCONF/RESTCONF 3) Definition of ephemeral datastore for NETCONF/RESTCONF 4) YANG "ephemeral" statement 5) NETCONF protocol extensions for the ephemeral datastore -- defined as a NETCONF capability 6) RESTCONF protocol extensions for the ephemeral datastore -- defined as RESTCONF protocol capability Notes on technical details ------------------------------------ 1) ephemeral datastore is never locked 2) ephemeral datastore treated as N client panes - server picks how many clients it supports - multi-head support is optional since max-clients allowed to be 1; 3) each client has a unique priority container i2rs-clients { leaf max-clients { config false; mandatory true; type uint32 { range "1 .. max"; } } list i2rs-client { key name; unique priority; leaf name { ... } leaf priority { ... } } } If a client is not present in the i2rs-client list, then the worst priority value is assigned The best possible priority needs to be reserved for the system, or the protocol has to make a special case of system-set data 4) each client writes into its own pane so there is no conflict within a pane; Difference is really what the server retains from a partial or failed edit. Should be OK to save nothing or save all (caching) 5) a partial operation is one where some subset of the written data is not applied because of better priority for that node; Only allowed if the error-option is stop-on-error or continue-on-error --> NETCONF stop-on-error and continue-on-error are not going to work. There is no mandated processing order for edits Perhaps I2RS can force some processing order to support partial edits IMO, all-or-nothing is the only option that is interoperable. --> NETCONF has no way of reporting which edits were accepted and which were rejected, for partial operations. Perhaps I2RS can add new error handling response data (BTW, all of this was removed from NETCONF (RFC 6241) because it was too complicated, and nobody implemented it because it was too complicated. I2RS WG should take note of that). 6) caching is optional; a server may retain the pane for each client; if not supported then the pane never contains unaccepted data; i.e. the server will return an error and not retain the edit that caused the error; caching allows the server to apply lower priority data when higher priority data is removed Not sure if examples should be in a separate appendix of mixed into the normative text (like YANG RFC) Andy On Fri, Sep 18, 2015 at 8:49 AM, Susan Hares <shares@ndzh.com> wrote: > Andy: > > > > I understand that Kent is very busy. I proposed that I start off draft > and hand it over to another one of the routing I2RS authors. I will send > out a draft early next week. > > > > Sue > > > > *From:* I2rs-proto-dt [mailto:i2rs-proto-dt-bounces@ietf.org] *On Behalf > Of *Andy Bierman > *Sent:* Friday, September 18, 2015 11:12 AM > *To:* Susan Hares > *Cc:* i2rs-proto-dt@ietf.org > *Subject:* Re: [I2rs-proto-dt] FW: Join WebEx meeting in progress: i2rs > protocol design team > > > > Hi, > > > > I have asked Kent to be the lead author on this draft, > > but he does not have time. I think a routing person should > > be the main author. > > > > The mechanics of editing an ephemeral datastore are somewhat > > straight-forward. The overlap of priority-based dependencies > > can cause problems. Detecting those problems so nobody ever > > puts a bad edit in the server will be extremely complicated and > > the I2RS server could slow down 1000X just to validate all these > corner-cases. > > > > IMO it would be better if a routing person laid out the best operational > options for routing, > > and then a YANG expert can find the most optimal way to do that. > > > > > > Andy > > > > > > > > On Fri, Sep 18, 2015 at 6:47 AM, Susan Hares <shares@ndzh.com> wrote: > > Hi all: > > > > This is the design team meeting number. I will be on-line to discuss > next-steps for 20 minutes. Andy and Kent were going to work up text. > I’ve not seen any text from Andy or Kent. My next steps are to work begin > to work on text? > > > > Any thoughts? > > > > Sue > > > > *From:* I2RS Working Group [mailto:messenger@webex.com] > *Sent:* Friday, September 18, 2015 9:44 AM > *To:* shares@ndzh.com > *Subject:* Join WebEx meeting in progress: i2rs protocol design team > > > > Hello, > > My WebEx meeting is in progress. > > Join me now from a browser, phone, or video conferencing system or > application. > > > > > > > > *i2rs protocol design team* > > Friday, September 18, 2015 > > 9:43 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr > > > > > > > > *Join WebEx meeting* > <https://ietf.webex.com/ietf/e.php?MTID=mc24852d4ea59aea3246ff757cf85255d> > > > > Meeting number: > > 645 703 803 > > Meeting password: > > proto.fun > > > > > > > > *Join by phone* > > *1-877-668-4493* Call-in toll free number (US/Canada) > > *1-650-479-3208* Call-in toll number (US/Canada) > > Access code: 645 703 803 > > Toll-free calling restrictions > <http://www.webex.com/pdf/tollfree_restrictions.pdf> > > > > > > > > Can't join the meeting? Contact support. <https://ietf.webex.com/ietf/mc> > > > > > > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you automatically > consent to such recordings. If you do not consent to being recorded, > discuss your concerns with the host or do not join the session. > > > > > _______________________________________________ > I2rs-proto-dt mailing list > I2rs-proto-dt@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs-proto-dt > > >
- [I2rs-proto-dt] FW: Join WebEx meeting in progres… Susan Hares
- Re: [I2rs-proto-dt] FW: Join WebEx meeting in pro… Andy Bierman
- Re: [I2rs-proto-dt] FW: Join WebEx meeting in pro… Susan Hares
- Re: [I2rs-proto-dt] FW: Join WebEx meeting in pro… Andy Bierman
- Re: [I2rs-proto-dt] FW: Join WebEx meeting in pro… Susan Hares
- Re: [I2rs-proto-dt] Join WebEx meeting in progres… Dean Bogdanovic
- Re: [I2rs-proto-dt] Join WebEx meeting in progres… Andy Bierman
- Re: [I2rs-proto-dt] Join WebEx meeting in progres… Andy Bierman
- Re: [I2rs-proto-dt] FW: Join WebEx meeting in pro… Anu Nair
- Re: [I2rs-proto-dt] FW: Join WebEx meeting in pro… Andy Bierman