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
>