Re: [Gen-art] Gen-art telechat review of draft-ietf-i2rs-traceability-09
Elwyn Davies <elwynd@folly.org.uk> Thu, 19 May 2016 10:16 UTC
Return-Path: <elwynd@folly.org.uk>
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 397F612D830; Thu, 19 May 2016 03:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 DTgSIJfYIGga; Thu, 19 May 2016 03:16:04 -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 2A79E12D7EC; Thu, 19 May 2016 03:16:04 -0700 (PDT)
Received: from c.b.2.4.9.b.3.7.7.7.c.2.e.c.0.8.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:80ce:2c77:73b9:42bc]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <elwynd@folly.org.uk>) id 1b3Kzn-0004jh-P8; Thu, 19 May 2016 11:16:00 +0100
To: Elwyn Davies <elwynd@dial.pipex.com>, 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> <e874f9d3-024f-54da-1f65-f12b1ebd7c22@dial.pipex.com> <7aaa1caa-f6df-0311-9e11-96a847efe625@cisco.com> <9896590b-2cf9-258e-7a59-9244c471065d@dial.pipex.com>
From: Elwyn Davies <elwynd@folly.org.uk>
Message-ID: <355f5056-fc2f-3b0e-bfa1-cd7cda010763@folly.org.uk>
Date: Thu, 19 May 2016 11:16:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <9896590b-2cf9-258e-7a59-9244c471065d@dial.pipex.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/GUHl19lvCfsNOh7PPB1JkIcoW1I>
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: Thu, 19 May 2016 10:16:11 -0000
Hi, Joe. I checked through the changes in -11 and that all looks good now. Thanks, Elwyn On 13/05/2016 21:43, Elwyn Davies wrote: > Hi, Joe. > > Thanks for the heads up. > > Apologies - I missed one question that I should have asked. You have > removed the idea that the specified fields are mandatory in s5.2. My > original issue with this was about whether you would envisage that > implementors could add additional, optional fields to the basic set, > and if so would it be good to mention/explain how this would be handled. > > The current state gives a rigid set of fields in each trace report > with no flexibility (or at least not within the specification). Is > this what the authors intended? > > Cheers, > Elwyn > > On 13/05/2016 16:36, Joe Clarke wrote: >> On 5/11/16 15:11, Elwyn Davies wrote: >>> Hi. >>> >>> I had a look at the revised diff. Looks pretty good now. >>> >>> Couple of minor points in line below. >> >> Thanks, Elwyn. We have posted rev -10 of the draft, which should >> address all of your comments. >> >> Joe >> >>> >>> 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 >>> >> > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art >
- [Gen-art] Gen-art telechat review of draft-ietf-i… Elwyn Davies
- Re: [Gen-art] Gen-art telechat review of draft-ie… Jari Arkko
- Re: [Gen-art] Gen-art telechat review of draft-ie… Joe Clarke
- Re: [Gen-art] Gen-art telechat review of draft-ie… Elwyn Davies
- Re: [Gen-art] Gen-art telechat review of draft-ie… Joe Clarke
- Re: [Gen-art] Gen-art telechat review of draft-ie… Elwyn Davies
- Re: [Gen-art] Gen-art telechat review of draft-ie… Joe Clarke
- Re: [Gen-art] Gen-art telechat review of draft-ie… Elwyn Davies
- Re: [Gen-art] Gen-art telechat review of draft-ie… Joe Clarke
- Re: [Gen-art] Gen-art telechat review of draft-ie… Elwyn Davies