Re: [Gen-art] Gen-art telechat review of draft-ietf-i2rs-traceability-09

Elwyn Davies <elwynd@dial.pipex.com> Wed, 11 May 2016 19:11 UTC

Return-Path: <elwynd@dial.pipex.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE4512D749; Wed, 11 May 2016 12:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
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 Ur4wroTabQ0z; Wed, 11 May 2016 12:11:50 -0700 (PDT)
Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30:5054:ff:fe5e:1643]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3DA12D595; Wed, 11 May 2016 12:11:50 -0700 (PDT)
Received: from 0.e.9.b.a.b.a.a.c.d.b.2.9.6.c.c.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:cc69:2bdc:aaba:b9e0]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <elwynd@dial.pipex.com>) id 1b0ZXu-0005qa-LP; Wed, 11 May 2016 20:11:47 +0100
To: Joe Clarke <jclarke@cisco.com>, General area reviewing team <gen-art@ietf.org>
References: <572B4D51.10003@dial.pipex.com> <e8a0bf59-f1ea-3710-9b3b-2820ea1ef64b@cisco.com> <d8db28ea-3560-ecd5-d4a4-4a8070b07af7@dial.pipex.com> <f3b683af-7903-639d-b857-8780c49cd35c@cisco.com>
From: Elwyn Davies <elwynd@dial.pipex.com>
Message-ID: <e874f9d3-024f-54da-1f65-f12b1ebd7c22@dial.pipex.com>
Date: Wed, 11 May 2016 20:11:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <f3b683af-7903-639d-b857-8780c49cd35c@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/99Tgal0q6vFHRjXmHaNXYfpOWnk>
Cc: draft-ietf-i2rs-traceability.all@ietf.org
Subject: Re: [Gen-art] Gen-art telechat review of draft-ietf-i2rs-traceability-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2016 19:11:53 -0000

Hi.

I had a look at the revised diff.  Looks pretty good now.

Couple of minor points in line below.

Cheers,
Elwyn

On 11/05/2016 16:18, Joe Clarke wrote:
> On 5/10/16 17:51, Elwyn Davies wrote:
>> s1, para 2: s/describes use cases/describe use cases/
>
> Fixed.
>
>>
>> s5.2, Event ID:
>>> An event can be a Client authenticating with the Agent, a Client to
>>> Agent operation, or a Client disconnecting from an Agent.
>> This is a good thing, but I am not sure that the format provides a way
>> to identify the authentication and disconnection events.
>
> The intent was that these would be Operations (i.e., AUTHENTICATE 
> CLIENT, DISCONNECT CLIENT).  There is nothing in the text that 
> precludes this.  We can explicitly state this.
I think stating it explicitly would be a good idea.
>
>
>>
>> s5.2, Starting Timestamp:
>> [I don't understand 'three points of prevision'.] Maybe...
>> OLD:
>> Given that many I2RS operations can occur in rapid succession, the use
>> of fractional seconds MUST be used to provide adequate granularity.
>> Fractional seconds SHOULD be expressed with at least three points of
>> prevision in second.microsecond format.
>> NEW:
>> Given that many I2RS operations can occur in rapid succession, the
>> fractional seconds element of the timestamp MUST be used to provide
>> adequate granularity.  Fractional seconds SHOULD be expressed with at
>> least three [or more?] significant digits in second.microsecond format.
>> END
>
> Changed.
Do you think millisecond resolution will be good enough?  I put in three 
because of the 'three points of prevision'   but wonder if you might 
need something closer to microsecond resolution in high throughput 
routers?  I don't know what might be desirable - I have some experience 
of a similar logging system (DTN2) and full microsecond resolution is 
occasionally useful.
>
>
>>
>> s5.2, Ending Timestamp:
>> See the comments on the Starting Timestamp - though I think you could
>> just refer to the words in the Starting Timestamp and avoid duplication.
>
> Done.
>
>>
>> s7.4/s7.4.3: Given that the I2RS pub-sub access method is
>> mandatory-to-implement, i think I-D.ietf-i2rs-pub-sub-requirements has
>> to be a Normative Reference.
>
> Changed.
>
> See the new text at 
> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html 
> .
>
> Thanks again for the review!
>
> Joe