Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Fri, 09 March 2018 14:44 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 2A17B128961; Fri, 9 Mar 2018 06:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=ruT1OjUE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ffoP73GI
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 x9sI9tcNjg1Y; Fri, 9 Mar 2018 06:44:27 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4B2126D85; Fri, 9 Mar 2018 06:44:27 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E675220E1C; Fri, 9 Mar 2018 09:44:26 -0500 (EST)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 09 Mar 2018 09:44:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=WQrflaGriURp2o+0QPOZ77VQhttcG 7j0fmUH6D/Dg28=; b=ruT1OjUEFkFYKwZKGB5gqQyKg/ebg1NzA4HGnLOOUk3P9 F8O1OPqOkIAwJBt6meGWaNHVUhdLp939wg2aJMQ9HX2p9eCQLCWbMxWhi5FLZY2Y 06I4lwOA2mXNVoThdYYAgynPh4oH+Glr9ieIMkWS8PWKLVFkLyP6Z7FmMI2H7jcm 0ugoAf6YWAztwOCR4Ad+fsXLskK0iu1D/OOIOYj9JScwvJsTY3wxfAfKL8VwZhkk JigH+hkCUNVNGAsqy58ifTcBoIx8eSEW9GqpnUHIAZfhz0EW5+zZ+BRaogeOGOi7 LpXlgQqb9cr5zrmV918rUM886wiQmoRsjSKpZnxLA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=WQrfla GriURp2o+0QPOZ77VQhttcG7j0fmUH6D/Dg28=; b=ffoP73GI8cbXd2NCrrwXws R2WZRoadXVUpTibwyhssxJsMuPIXU+hoV5Nk/GXYu4wWYS2KRLmu3RCB78RD+Sjh Klut7DhQDXSq7lqrU/J+vQH10Zo31CIqJPtP7MEaBpMGu0/RR7ylYCge5PAQHrLc INQiXEL1+WIa030Uy64AWrFapkluH9sMsnnC7I9AwJqBrY084jH1BPifr7quT4oE 7ZDxurp2FjHnktRnNHRY9s4sE7ojWmZ8h2r9PTo8xHNH7xhIKJ+2vvc8jymUaWUP O99deM/UViHa8sJ55D09kC+bxZ7mp/DeAC1pE+4Zh8xfJ47nCWBp+bzfCyQuB97Q ==
X-ME-Sender: <xms:yp2iWuMQoCcNnLsvs5k-nY9hsW2QmNWCz75onSrz-B2SXlPbjJg96g>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id C32E99E0FF; Fri, 9 Mar 2018 09:44:26 -0500 (EST)
Message-Id: <1520606666.3093526.1297375920.65A6D407@webmail.messagingengine.com>
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: "Clyde Wildes (cwildes)" <cwildes@cisco.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-netmod-syslog-model@ietf.org, Lou Berger <lberger@labn.net>, Kent Watsen <kwatsen@juniper.net>, netmod-chairs@ietf.org, netmod@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-54087d22
Date: Fri, 09 Mar 2018 14:44:26 +0000
References: <152036678480.28267.2878978732820211120.idtracker@ietfa.amsl.com> <BF7BE65C-518F-4789-AE3B-9C7B3E5CE9BF@cisco.com>
In-Reply-To: <BF7BE65C-518F-4789-AE3B-9C7B3E5CE9BF@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SJdo4JcOJCRaOjJaI0fziuYXNh4>
Subject: Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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, 09 Mar 2018 14:44:29 -0000

Hi Clyde,

On Thu, Mar 8, 2018, at 9:28 PM, Clyde Wildes (cwildes) wrote:
> Alexey,
> 
> Your minor comments are addressed below…
> 
> On 3/6/18, 12:06 PM, "Alexey Melnikov" <aamelnikov@fastmail.fm>; wrote:
> >     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     Thank you for this document.
>     
>     I also prefer for TCP to be documented, if used in real world.
>     
>     Some minor comments:


>     2) On page 19:
>     
>     Example: compare->equals and action->no-match means
>     messages that have a severity that is not equal to the
>     specified severity will be logged.";
>     
>     Do you mean "action->block" instead of "action->no-match"?
> 
> [clw] An equals compare with action no-match means log the message, not 
> block it.

Your document only talks about "action->no-match" in one place in the example. Has terminology changes over years and you forgot to update the example?

It is possible I am confused here.

>     
>     3) When logging to file: how is the file name constructed from the 
> name file:
>     URI if multiple files are preserved by the system? E.g. if the log 
> file is
>     rotated daily and 5 last files are preserved, how does each 
> individual filename
>     look? If I understood how this is used, this needs more 
> clarification.
> 
> [clw] We decided to leave this for the implementer as file systems may 
> be different for different implementations.

I think you should clarify in the document what is the purpose of filename and say something about the above. I appreciate that this might not be needed for interoperability, but what you have in the document doesn't provide enough details to implement this aspect. Even saying that implementations can derive log specific filenames from the base one instead of saying nothing would be better.

Thank you,
Alexey