Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*

"Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com> Sat, 04 January 2014 12:06 UTC

Return-Path: <mehmet.ersue@nsn.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 7FC871ADF44 for <opsawg@ietfa.amsl.com>; Sat, 4 Jan 2014 04:06:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5] 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 Yk3-Whk0vSxA for <opsawg@ietfa.amsl.com>; Sat, 4 Jan 2014 04:06:40 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2D53D1ADF43 for <opsawg@ietf.org>; Sat, 4 Jan 2014 04:06:39 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s04C6Ta9006058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 4 Jan 2014 13:06:29 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s04C6SG9015041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Jan 2014 13:06:29 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 4 Jan 2014 13:06:28 +0100
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Sat, 4 Jan 2014 13:06:28 +0100
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: "ext Bert Wijnen (IETF)" <bertietf@bwijnen.net>, "opsawg >> \"opsawg@ietf.org\"" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*
Thread-Index: AQHPB5hTXASYx/AkA0mvvcW3JIGoM5py+qUAgAA/XQCAAUDzAA==
Date: Sat, 04 Jan 2014 12:06:27 +0000
Message-ID: <E4DE949E6CE3E34993A2FF8AE79131F82489B0@DEMUMBX005.nsn-intra.net>
References: <52C32AF3.3040103@bwijnen.net> <52C52968.7050404@bwijnen.net> <E4DE949E6CE3E34993A2FF8AE79131F824821E@DEMUMBX005.nsn-intra.net> <52C6F98E.5050805@bwijnen.net>
In-Reply-To: <52C6F98E.5050805@bwijnen.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.110]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1273
X-purgate-ID: 151667::1388837189-00001A6F-3C6663A3/0-0/0-0
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: Sat, 04 Jan 2014 12:06:42 -0000

... 
> > 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.

Agree.
 
... 
> >> - 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.

I think the requirements can be justified. Will add text. 

Cheers,
Mehmet