IETF Logo Mail Archive

Re: [netmod] Question on draft-wu-netmod-factory-default

Alex Campbell <Alex.Campbell@Aviatnet.com> Tue, 26 March 2019 21:04 UTC

Return-Path: <Alex.Campbell@Aviatnet.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8420E120BAB for <netmod@ietfa.amsl.com>; Tue, 26 Mar 2019 14:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.com
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 vZERhDy2qFw4 for <netmod@ietfa.amsl.com>; Tue, 26 Mar 2019 14:04:26 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810049.outbound.protection.outlook.com [40.107.81.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A33D120BA5 for <netmod@ietf.org>; Tue, 26 Mar 2019 14:04:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ir4J5N70Wo3j0b9ORs8JmxfYCWjB5J26P/bwyqUUVrU=; b=daTsDkv9Cxkr8Onh4CXF/kOXSsQxxzUZ+B6uCru1VSBjMd6DAOHpOaZCTkaaIZAbY6B/iD5SB3dmMq3FPDDWHoJ3QcUBVxYtiQX9HdJLYA/M0W/KK9P06N02Lg5YGO/ZFXI37qnSfB1C5pGKXwmMI2c4DGEix339olwE0ZXvNEc=
Received: from MWHPR2201CA0059.namprd22.prod.outlook.com (2603:10b6:301:16::33) by MWHPR2201MB1119.namprd22.prod.outlook.com (2603:10b6:301:33::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.19; Tue, 26 Mar 2019 21:04:24 +0000
Received: from CO1NAM03FT057.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::208) by MWHPR2201CA0059.outlook.office365.com (2603:10b6:301:16::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1730.18 via Frontend Transport; Tue, 26 Mar 2019 21:04:24 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.54) smtp.mailfrom=Aviatnet.com; bogus.com; dkim=none (message not signed) header.d=none;bogus.com; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.54 as permitted sender) receiver=protection.outlook.com; client-ip=192.147.115.54; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.54) by CO1NAM03FT057.mail.protection.outlook.com (10.152.81.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1730.9 via Frontend Transport; Tue, 26 Mar 2019 21:04:23 +0000
From: Alex Campbell <Alex.Campbell@Aviatnet.com>
To: Joe Clarke <jclarke@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Question on draft-wu-netmod-factory-default
Thread-Index: AQHU5BdzaRAHgL+6bUajrS0KOdVWNQ==
Date: Tue, 26 Mar 2019 21:04:07 +0000
Message-ID: <1553634262537.25586@Aviatnet.com>
References: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com>, <665b7eef-54d1-6bd4-16bb-a66b820f5ebe@bogus.com>
In-Reply-To: <665b7eef-54d1-6bd4-16bb-a66b820f5ebe@bogus.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.54; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(396003)(39850400004)(346002)(376002)(2980300002)(189003)(199004)(36736006)(5660300002)(106002)(2906002)(6246003)(106466001)(6116002)(3846002)(356004)(6666004)(6306002)(336012)(6486002)(117636001)(97876018)(4326008)(8676002)(53416004)(86362001)(25786009)(118246002)(8746002)(110136005)(246002)(8936002)(316002)(23756003)(11346002)(229853002)(26005)(7696005)(76176011)(36756003)(966005)(53546011)(102836004)(956004)(126002)(2616005)(305945005)(47776003)(478600001)(50466002)(7636002)(476003)(7736002)(186003)(486006)(446003)(2501003)(7596002)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR2201MB1119; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3eb2c2be-b275-4882-7f2f-08d6b22e9fdb
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MWHPR2201MB1119;
X-MS-TrafficTypeDiagnostic: MWHPR2201MB1119:
X-MS-Exchange-PUrlCount: 1
X-Microsoft-Antispam-PRVS: <MWHPR2201MB1119B74A3D89B60189F6B625875F0@MWHPR2201MB1119.namprd22.prod.outlook.com>
X-Forefront-PRVS: 09888BC01D
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: 8IxElRM9d6OyMkDr/pfwuuHDw0ii3J2S5yY6cJNGyr1iYwfsTXhZatDrSpjcF3FCuYy0Lh5yCBf8TXNVQaWMqy8SMRnr8wPkWbowQeHPr2KqhukFhaENLC+litXL55/aYFR4kHdbxSQXGIZcCU7ZHQobsp+DavFQKGuZYNyJPnoKwecpD9hVqguIv4gc50ZdFGmZXQlMsOSvvHG72e1UR1uundCVpC0J/LVcBOB9+8vArF4nfVmR4+6+XdG3BhToGpMxW4SAeq4HIyzbqIyCTj7vvHhjumhqKnEyhCEFCfE5lX0dnTSlsdQFqihUinR7JK+/uOTpNolT2qa2k/05uojYxEWeuqxhaZrpcXr1kaH5BDQC9XQQ2Mr7s09t4+O9TiyZ/lich5LEHyR5U1XkeCD1e1NFa6IMR13ZvUfh35o=
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2019 21:04:23.8615 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3eb2c2be-b275-4882-7f2f-08d6b22e9fdb
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.54]; Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR2201MB1119
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SolnnlK6rEzIwNdiJce366zGLvc>
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 21:04:30 -0000

As I understand it,the only purpose for the candidate and startup datastores is to indirectly set the contents of the running datastore.

Therefore it wouldn't make sense to have different factory defaults for the running, startup and candidate datastores. And those are the only writable ones.

Joe, which other datastores were you thinking of?

Alex


________________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of joel jaeggli <joelja@bogus.com>
Sent: Tuesday, 26 March 2019 8:18 p.m.
To: Joe Clarke; netmod@ietf.org
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default

On 3/25/19 07:14, Joe Clarke wrote:
> I support the need for being able to reset a DS to its factory default.
> However, I have a question on the current design of the model and the
> "factory-default" DS.
>
> It seems to me that this is a single DS that might have been intended to
> reset running or startup.  However, what if I have different DSes that
> each have unique factory default data?  If I choose to extend
> factory-default with a new identity of my other DS, how can I indicate
> that the target DS will be reset to _that_ DS?  Does that make sense?
>
> Or if I do a <get-data> on a factory-default DS, how do I know what
> other DSes does this DS pertain?  Perhaps the server will use this to
> reset a given DS, but how would a user know that (other than perhaps
> naming of the factory-default DS)?
>
> Maybe the module needs a mapping to let the client know what DS will be
> used to reset what other DS?

the germ of the idea is sensible enough. reset a DS to it's factory state.

When it meets reality of course is that there seem to be a bunch of
variants that seem like pretty compelling use cases.

reset the whole device being one of them.

the specification of a factory-default datastore and then

   o  startup configuration datastore

   o  candiate configuration datastore

   o  running configuration datastore

actually sound a bit implementation specific though I recognize that
most network operating systems due tend to follow models that at least
superficially resembled that.

I'm generally sympathetic to the application the draft proposes.

>
> Joe
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

v2.23.0 | Report a Bug | By Email