Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Kent Watsen <kwatsen@juniper.net> Fri, 24 February 2017 00:13 UTC

Return-Path: <kwatsen@juniper.net>
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 1E3F51293E1; Thu, 23 Feb 2017 16:13:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 MxNuZ1ICF7KU; Thu, 23 Feb 2017 16:13:23 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0106.outbound.protection.outlook.com [104.47.40.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA42B1204D9; Thu, 23 Feb 2017 16:13:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pN0DFFlf5dN00al8kB4TAHX+clYnje3LrwK1G+K8UL8=; b=hgQ55tngU69W6URzT1ZO1Jnj52ENGGQHeu1K2pW6hIj4Hq10fMjKcxRLuAoaBoBCaaWnNBrH8lmbDITFrA2fGS/5XGGaj/ylf5to0fSpEgpLDaZdKr6N6ADplOdoryCWInfpvm//zgeGgEV/ik4ALK+se1vwx4frMJgYfaVIe90=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Fri, 24 Feb 2017 00:13:22 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0933.011; Fri, 24 Feb 2017 00:13:22 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Alexander Clemm <alexander.clemm@huawei.com>, "draft-ietf-netmod-syslog-model@ietf.org" <draft-ietf-netmod-syslog-model@ietf.org>
Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Thread-Index: AQHSVaWfIiJK4a4BSkqW0KAWiGRnmqEGzUbWgBWyuYCABGZCgIABcw2AgBG2twCANNH3AIALMemAgABwHICAAYtwAIABVloA///N7QCAAGQDAP//t/2AgABgPQD//7aKgA==
Date: Fri, 24 Feb 2017 00:13:22 +0000
Message-ID: <033D3CA2-7297-48C8-A5BD-B723F7F1911B@juniper.net>
References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <1481689016940.22442@Aviatnet.com> <CABCOCHSXVrZG-kz2TMmptcQ3pZ76u+MWse=0NVNY0h4q5GzrKw@mail.gmail.com> <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> <CABCOCHRAugaAcDN589AOUYW6J4dntuX_azouEtzxcu02_TfA4w@mail.gmail.com> <1CC274D2-72B9-4F79-A70F-3DF332C65A60@cisco.com> <44C50B18-8918-47E4-A9FE-F4A676E64AA1@cisco.com> <FEF5A115-37CA-426E-A7AA-DD81BA840C36@juniper.net> <CABCOCHQP4hGaFT1onhyNi9N6Y_NgUxYusPOJt_9wRn3ZcdLZMg@mail.gmail.com> <BBF09820-4986-49A7-AE96-6360E93C671E@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF818AA@SJCEML703-CHM.china.huawei.com> <02B9298C-631A-46F7-9FA9-19B1959327FE@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81C18@SJCEML703-CHM.china.huawei.com> <DB23E987-42CA-4345-B712-3116A26228DC@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CBA@SJCEML703-CHM.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CBA@SJCEML703-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [96.231.191.4]
x-ms-office365-filtering-correlation-id: cabe0244-51b1-426b-33ae-08d45c49f1a1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0501MB1452;
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 7:rAHnQqstNSSi+oI810cs7ZnWzX7TbWXcvZoOR86MY1V7tVy7wV9gTu/aFvN6SL1p2Lm52gh7W7vUysclENOs0yquvjWhshLivpfH5N5rZBM5/CCK6aKnyR60e2DAxzSZUv8trt8KUeluNTJ+W3rudhKjDkE4vVWhpuERn/fuRqmr76Obd1mBfDW8H0nyBRLF1MjMYNOS6Q/0aY5oyljsQZb2lcLIIi67ydDfbEOwrKyGS5YR5JMjH3GsBIknWVct/NfdhaXxD6NGaNBKtw/CcE8RAHIZ0uWztHoyjzJ8LUqh7Zz7ZqrOzeJfdbKG5z8zYxyOPrA5zgBkVPsqkxgdpw==
x-microsoft-antispam-prvs: <CY1PR0501MB14523E231D08A3BC9DAA3333A5520@CY1PR0501MB1452.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39850400002)(39410400002)(39450400003)(39860400002)(199003)(189002)(99286003)(122556002)(6436002)(66066001)(81166006)(8676002)(81156014)(6512007)(54356999)(76176999)(2906002)(6306002)(54896002)(36756003)(33656002)(4326007)(8936002)(2950100002)(3280700002)(86362001)(50986999)(101416001)(2900100001)(25786008)(68736007)(83716003)(189998001)(230783001)(7736002)(83506001)(97736004)(82746002)(6116002)(105586002)(6486002)(53936002)(3660700001)(4001350100001)(6246003)(5660300001)(77096006)(102836003)(93886004)(3846002)(2501003)(92566002)(106356001)(6506006)(106116001)(38730400002)(229853002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_033D3CA2729748C8A5BDB723F7F1911Bjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 00:13:22.1386 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZxJ7bA-MNCGuy49Dv0c595P16uM>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 24 Feb 2017 00:13:25 -0000

> <ALEX>
> True, this is keystore territory, and I don’t think this should venture in that direction – the [sic]
> can be considered clearly out of scope.

Why would it be out of scope?  Seems like this is actually what you might want given what you
wrote below...


> However, what would actually make sense would be to offer a configuration option that
> clearly states which of the signature options (and signing material) should be used.
> Clearly the ability to configure this will be needed.

I think I agree here but, if I understand you correctly, wouldn't this be best accomplished
via references to keystore keys/certificates?


> If you want to accommodate this,

Actually, I'm just probing the issue.  I was hoping the response was going to be "this was discussed
by the working group here: <link to email-thread>" and we could move on.   But since that does
not seem to be the case, it would be good for the WG (not me) to decide if we want/need to
accommodate this.  What do people think?

Options:
  a) leave as is (and document the shortcoming)
  b) remove signing-options (add back later when ready)
  c) address the issue now

> you probably need to consider another modification to the model:  It is conceivable that there
> could be multiple signers, and different signers might each use a different option.  Therefore, to
> allow for differentiation by signer, you might want to consider introducing a corresponding
> parameter under a list of signers.  (You could even move the configuration parameters into this
> list, although frankly I would opt to keep those parameters global (and the use of the model
> simple), not per-signer.)

True, and potentially a reason to not go with (a) as, with that option, it may not
be easy to add in this kind of flexibility later in a backwards-compatible manner.


Thanks,
Kent        // shepherd