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

Kent Watsen <kwatsen@juniper.net> Thu, 23 February 2017 22:51 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 4C66B129BE1; Thu, 23 Feb 2017 14:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.788
X-Spam-Level:
X-Spam-Status: No, score=-3.788 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_H2=-1.887, 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 HIMRR3PXDoZN; Thu, 23 Feb 2017 14:51:50 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0104.outbound.protection.outlook.com [104.47.34.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23915129BDA; Thu, 23 Feb 2017 14:51:50 -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=pLzDclLWg0f1MiWX82gfVOz2vqzCpMarXVnpP0/JLuU=; b=f7mMR4YV4oEQr9UJ/UWLeCPT8hepreEyHJ5mhOZmdNB2CwywGiiWUa2h6qjTPX1S0MFXz7HW/a15ID2I+J0vpNemaf64e8OkVOmyzk3Kvey17z4B1PRAHZqC3HqfgWkNWrUP2YDONY1GJaqbfGT95KhFhTxQEzyMuPQgtl4nKMM=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 23 Feb 2017 22:51:48 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 22:51:48 +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/2A
Date: Thu, 23 Feb 2017 22:51:48 +0000
Message-ID: <DB23E987-42CA-4345-B712-3116A26228DC@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>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81C18@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: 788f922b-208e-477c-efbc-08d45c3e8cde
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444;
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:ZZ03pkMi8dBh136BNsSiqldLRmgy7pjpW3734PMnIwzoj2sgb51gTg6Gco7cS1MKuKoKDTmIqwEYFK+l2fpJ9FqoXzNyq7UwVu66CNXG0Pehd5Py//zNVIEbSIrmoDHvV44nh6N3ADGv/lmKA1Kw/yrbuCVKVfSi1yQFxfYQcwZKYGMy1tJQHt64TJVWpIFVMYapFmP1Il2Iugtn8sKlexarUKUNT5dcqcyIUF/2PxI28ihV6VActJFEp6ElRafdq929CE8si3pA90xklOm9kG85tufQ6uxsPgsmuxdDSnv0WM4r1rqhcGJ/5D2L8hfNurG2QkQ9bvkesCsABAzDww==
x-microsoft-antispam-prvs: <BN3PR0501MB1444B6F72A235813767B801CA5530@BN3PR0501MB1444.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)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39410400002)(39840400002)(39850400002)(199003)(189002)(2950100002)(3846002)(5660300001)(6116002)(102836003)(105586002)(2501003)(53936002)(101416001)(38730400002)(6246003)(33656002)(76176999)(68736007)(2900100001)(50986999)(106356001)(2906002)(54356999)(3660700001)(106116001)(36756003)(4326007)(3280700002)(6506006)(6436002)(25786008)(122556002)(77096006)(6486002)(66066001)(8676002)(81166006)(83716003)(81156014)(82746002)(189998001)(83506001)(8936002)(6306002)(92566002)(4001350100001)(86362001)(230783001)(93886004)(99286003)(229853002)(6512007)(54896002)(7736002)(97736004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.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_DB23E98742CA4345B7123116A26228DCjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 22:51:48.6100 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/kXaI4iC7n85H4QcClxBr4j8I-xM>
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: Thu, 23 Feb 2017 22:51:52 -0000

>> - should the leafs not starting with "cert-" start with "sig-", to better match section 6.1?
>
> <ALEX> No, that would actually match less and be misleading.   The parameters mentioned in 6.1.1
> refer to configuration parameters for certificate blocks, and are accordingly prefixed “cert”.  The
> parameters mentioned in 6.1.2 are related to Signature Blocks and are accordingly prefixed with
> “sig” (sigMaxDelay, sigNumberResends, sigREsendDelay, and sigResendCount).  So, you might
> actually want to consider prefixing max-delay, number-resends, resend-delay, and resend-count
> with“sig-“. </ALEX>

Exactly, we agree.   These were the leafs I meant by "not starting with 'cert-' ".


> Syslog-sign does not specify how these types got there and what key material they
> used.  Now, if you wanted to manage that as well, sure, but now you would be getting
> into TLS territory as you mention and I would think this should be kept outside the
> scope.

That Syslog-sign doesn't specify this is a good response as well.  But answer
me honestly, isn't it something that a device would have to have configured
and, if so, wouldn't it make most sense for that configuration to be in this
module?

FWIW, I don't think that it's TLS-territory so much as keystore-territory.


Thanks,
Kent        // shepherd