Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*
Andy Bierman <andy@yumaworks.com> Fri, 03 January 2014 18:23 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B971ADFC8 for <opsawg@ietfa.amsl.com>; Fri, 3 Jan 2014 10:23:21 -0800 (PST)
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 Cr8xvlDia5xN for <opsawg@ietfa.amsl.com>; Fri, 3 Jan 2014 10:23:17 -0800 (PST)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id C28C81ADFB1 for <opsawg@ietf.org>; Fri, 3 Jan 2014 10:23:17 -0800 (PST)
Received: by mail-qc0-f175.google.com with SMTP id e9so15141771qcy.34 for <opsawg@ietf.org>; Fri, 03 Jan 2014 10:23:10 -0800 (PST)
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=nYlQSlkvrrIlSuel4BhGhIw/r3Y+5G6v7gdpBww4clo=; b=I0Ommal4cFfWDdkLCaK8mhccBeLLnUwVLVQTao/3/Vq4opylDj2q77wSifHulxxIMe sZ6d13TtIVdJTQFiXHu8xZMR88ZM0wo1IsiaOeS8IZCCbxyh/s8+pvC3pOQDjRj9R+8I sgMolMFQnBsmAzdzmenfRmPNsnItF8YOOSpJq0fEo8fW48iyRGi5m1rdaBdjxEWSgsTM rAuKE1qLrdpaNeZj6P5j/7U2HPYC1k31HO6QUbwjDoznGS1vczWCtfNNHkzMEAi3H3UE K0TJJNmTpOgetvfR5ZKK/8ZfS3lPnuCfxAZVXE/x4pC8JfDcb+7GUr4lf0ZjoLI+tgw/ GZaw==
X-Gm-Message-State: ALoCoQkAhMf4tMYna7sWqU8m6BIfvd/O4MMa+IU57L/zlj5VmBNzwmVv8acozBZi+HFQ6BfMENf1
MIME-Version: 1.0
X-Received: by 10.224.71.143 with SMTP id h15mr51289792qaj.88.1388773389515; Fri, 03 Jan 2014 10:23:09 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Fri, 3 Jan 2014 10:23:09 -0800 (PST)
In-Reply-To: <52C6F98E.5050805@bwijnen.net>
References: <52C32AF3.3040103@bwijnen.net> <52C52968.7050404@bwijnen.net> <E4DE949E6CE3E34993A2FF8AE79131F824821E@DEMUMBX005.nsn-intra.net> <52C6F98E.5050805@bwijnen.net>
Date: Fri, 03 Jan 2014 10:23:09 -0800
Message-ID: <CABCOCHRvyVx-0nUa+6RkGp0w5MyXxtiKLhLgUb1X9UG5M5cX2Q@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
Content-Type: multipart/alternative; boundary="047d7bdc8aa48e663d04ef1500bc"
Cc: "opsawg >> opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jan 2014 18:23:21 -0000
Hi, On Fri, Jan 3, 2014 at 9:55 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net>wrote: > .... >>> >> >> I wonder how you define the "minimal modular-function-set". Isn't this >> already a decision? >> The draft avoids defining function sets to be used. I assume different >> vendors will provide >> different monolithic devices. >> >> > There is two things that (in my view are/can be modular: > - the implementation > - the specification > > EVen if the specification is "modular", even then someone can chose to > implement it as a monolythic program/process I would think. And often that > can > save memory usage. > > I think this refers to the issues left unresolved by the "NETCONF Lite" discussions. The current NETCONF approach consists of a base protocol + several purely optional capabilities. This is a modular approach. The problem is that the base protocol is way too heavyweight for constrained devices. Another way to create modular functionality would look more like a hierarchy, not 1 mandatory blob + N optional blobs. NMS applications should be written so they can fall-back to lower functionality levels, in order to work with constrained devices. E.g. (not a complete list) Level 0: pre-configured; able to push pre-defined monitoring data Level 1: pre-configured; able to pull pre-defined monitoring data Level 2: pre-configured; able to pull user-defined filtered subsets of monitoring data Level 3: has config objects; requires a restart for new values to take affect Level 4: entire config (or pre-determined subset) can be replaced in bulk Level 5: ability to patch objects without replacing entire config Level 6: ability to lock datastores for write access Level 7: has transaction (all-or-none) capability Level 8: has recoverable transaction (confirmed-commit) capability Andy > > >>> - for requirement 4.9.001 >>> It might be good to add a refereence to RFC2914 ?? >>> Just thinking aloud. >>> >> Yes, RFC2914 is indeed interesting reference to add. >> >> >>> - for requirement 4.9.003 >>> is that more or less an "implementation" suggestion for requirement >>> 4.9.001 ?? >>> >> >> You are right. It could be seen as such. >> However, there might be different reasons why people would want to reduce >> the amount of traffic in the network. >> Congestion is one of them. One can also begin acting before congestion >> happens. WDYT? >> >> OK, maybe add a line of text about that then. IN my view it looked like > basically twice the > same requirement. But if you define it this way, then it can be seen as a > different requirement > may be. > > Bert > >> >>> See you all in the neaw year, which I hope is prosperous for you all. >>> >>> >> See you!!! Happy New Year!! >> >> Cheers, >> Mehmet >> >> >>> Bert >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>> >> >> _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >
- [OPSAWG] Call for reviewers of draft-ersue-opsawg… Warren Kumari
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Romascanu, Dan (Dan)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Warren Kumari
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Bert Wijnen (IETF)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Ersue, Mehmet (NSN - DE/Munich)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Ersue, Mehmet (NSN - DE/Munich)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Bert Wijnen (IETF)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Andy Bierman
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Ersue, Mehmet (NSN - DE/Munich)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Cao,Zhen
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Romascanu, Dan (Dan)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Juergen Schoenwaelder
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Romascanu, Dan (Dan)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Juergen Schoenwaelder
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Ersue, Mehmet (NSN - DE/Munich)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Sehgal, Anuj
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Ersue, Mehmet (NSN - DE/Munich)
- Re: [OPSAWG] Call for reviewers of draft-ersue-op… Ersue, Mehmet (NSN - DE/Munich)