Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 16 January 2014 07:37 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 C7FFB1AE2E4 for <opsawg@ietfa.amsl.com>; Wed, 15 Jan 2014 23:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level:
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 SfvHlPKNTC4D for <opsawg@ietfa.amsl.com>; Wed, 15 Jan 2014 23:37:51 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 327451ADBCD for <opsawg@ietf.org>; Wed, 15 Jan 2014 23:37:51 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D37E220048; Thu, 16 Jan 2014 08:37:38 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id D2lg95NBqsvs; Thu, 16 Jan 2014 08:37:38 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23EB120031; Thu, 16 Jan 2014 08:37:36 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 14DB02AA6572; Thu, 16 Jan 2014 08:37:34 +0100 (CET)
Date: Thu, 16 Jan 2014 08:37:34 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: James Nguyen <james.huy.nguyen@gmail.com>
Message-ID: <20140116073734.GA1160@elstar.local>
Mail-Followup-To: James Nguyen <james.huy.nguyen@gmail.com>, "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>, "opsawg@ietf.org" <opsawg@ietf.org>
References: <CANF0JMCZzziqvjvTJ0WaJ8Wo3kSNHDhhurmcYmX4FpcqWfq2+g@mail.gmail.com> <E4DE949E6CE3E34993A2FF8AE79131F8249B2D@DEMUMBX005.nsn-intra.net> <CANF4ybvR47wHioN61meNiR6b-DgXue0EnDy2gmHSQ=P4sSgkhA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CANF4ybvR47wHioN61meNiR6b-DgXue0EnDy2gmHSQ=P4sSgkhA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: Thu, 16 Jan 2014 07:37:54 -0000

On Wed, Jan 15, 2014 at 04:47:17PM -0500, James Nguyen wrote:
> Hi,
> 
> I really enjoy reading this draft.  In general, in my opinion is very
> useful for managing constrained devices.
> 
> I have a couple of questions/suggestions:
> 
> (1) Req-ID 4.3.002 Title: Capacity Discovery
> 
>      I don't quite understand this req.  Please be more specific.

Here is the text (it is _capability_ not _capacity_ discovery):

   Req-ID:  4.3.002

   Title:  Capability Discovery

   Description:  Enable the discovery of supported optional management
      capabilities of a device and their exposure via at least one
      protocol and/or data model.

Devices may have different levels of management support. This
requirement says that it should be possible to discover any optional
management capabilities. What is unclear here? How can we improve it?
 
> (2) Section 3.3 Configuration Management
> 
>      Session-oriented configuration protocol may be expensive for managing
> a large number of similar devices.  In a case when common redundant
> configurations is issued, reliable multicast with negative acknowledgement
> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast (NORM))
> would work best.  I suggest to add a reliable transport requirement in this
> section.  Moreover, a common data model would be needed.
> 
>      Stateless configuration update solution would also work well for
> constrained networks.

My assumption is that reliable multicast protocols are not simple and
bring their own can of worms. Can you point to prototype systems that
do successfully use reliable multicast to configure constrained
devices?

Can you also elaborate what "stateless configuration update solution"
means to you?

> (3) Section 3.8 Group-based provisioning
> 
>      As I mentioned in (2), a common data model would be required for
> common redundant configurations.  I suggest to add this requirement here.

Yes, perhaps we have to say something explicit about this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>