Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08
Joe Clarke <jclarke@cisco.com> Wed, 11 May 2016 22:21 UTC
Return-Path: <jclarke@cisco.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B75B12D593; Wed, 11 May 2016 15:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RyI9TxUTJFxJ; Wed, 11 May 2016 15:21:22 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD42012D521; Wed, 11 May 2016 15:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5767; q=dns/txt; s=iport; t=1463005281; x=1464214881; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=d2y/tUeJvte8NefVuXPFq0hD1EI5W1TMsyNghZz9tuI=; b=dqWh5EqN5lJ+0Vqz/M3XreL7kQsfazptNHwAr63R/PYcY9/JVzLaoiif qgl4YafvOH5ugicC3o3pSbkUgdp6JlBJO+4QDBZLIUYEoqChSb1AqUk/D 7bX12hkz0i9HFNd5yNKPZAu/jEk6Lf4EnaPWPkP715T3P1eYgpXhkbuFA 8=;
X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="272403085"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2016 22:21:00 +0000
Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4BML0YX008578; Wed, 11 May 2016 22:21:00 GMT
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <b8c9a8ad-6f2e-5f09-5bfd-9b39cb412959@cisco.com> <b758c78deaa54ca19375d49562576d9d@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com>
From: Joe Clarke <jclarke@cisco.com>
Organization: Cisco Systems, Inc.
Message-ID: <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com>
Date: Wed, 11 May 2016 18:20:58 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/TfQ0DAxiPkMt3pt02M_BPLLQGwk>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-i2rs-traceability@ietf.org" <draft-ietf-i2rs-traceability@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>
Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2016 22:21:24 -0000
On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: > Joe - > > Yes - this looks better to me. > > What about the "shadow boxes" for Applications/Clients? Do you have an example draft I could look at for that? Joe > > Les > > >> -----Original Message----- >> From: Joe Clarke (jclarke) >> Sent: Wednesday, May 11, 2016 8:19 AM >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.org >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >> >> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: >>> Joe - >>> >>> Apologies for the delayed response. I am a victim of my own email >>> infilters. :-( Inline. >> >> Thanks, Les. Have a look at >> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- >> 10.diff.html >> . I added a new line to show the flow in both directions. >> >> Joe >> >>> >>>> -----Original Message----- >>>> From: Joe Clarke (jclarke) >>>> Sent: Friday, April 29, 2016 10:44 AM >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; >>>> i2rs@ietf.org >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >>>> >>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: >>>>> Summary: This document is a well written document - easy to >> understand. >>>>> My compliments to the authors. I believe there is one minor issue >>>>> which I would like to see addressed before publication. >>>> >>>> Thanks for your comments and feedback, Les. Please see below for >>>> some replies and questions. >>>> >>>>> In Section 5.2 there is a definition of the information which is >>>>> required to be kept by an I2RS Agent for each I2RS interaction. I >>>>> would like to see the addition of "Request State" into this list. >>>>> Operationally each request could be in one of the following states: >>>>> >>>>> >>>>> >>>>> * Enqueued (or pending if you prefer) >>>>> >>>>> * In process >>>>> >>>>> * Completed >>>>> >>>>> >>>>> >>>>> The lack of such a state seems to imply that both the queue time and >>>>> the processing time are insignificant. While I think this may be the >>>>> case for many requests, it will not always be the case. In queue >>>>> time may be lengthy due to other load on the Agent. Also, some >>>>> requests - particularly destructive requests which involve cleanup >>>>> of resources - may take a significant amount of time to complete. >>>> >>>> Good observation. Traceability was aimed mainly at the termination >>>> of the request, but I like the idea of tracing the state machine. >>>> >>>>> >>>>> >>>>> >>>>> Along with this an additional timestamp - Processing Initiated - >>>>> would be useful to indicate when processing of the request actually >> began. >>>> >>>> I don't know we need a new timestamp. Perhaps we just need to >> rename >>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and >>>> "End Timestamp" to denote the time within the current state. What do >>>> you think? >>> >>> [Les:] My intent was to log the time at which the request began processing >> so that you can see whether a long delay in completion was due to enqueue >> delay or actual lengthy processing time. I am not adamant about this so if you >> want to stay with the two timestamps that is OK. >>> >>>> >>>>> s/Some notable elements on the architecture/ Some notable elements >>>>> of the architecture >>>> >>>> Fixed. Thanks! >>>> >>>>> >>>>> >>>>> >>>>> Figure 1 >>>>> >>>>> >>>>> >>>>> Not clear to me why Application IDs start at 0 but Client IDs start at 1. >>>> >>>> Ah. The numbers there are not IDs. They are the number of actual >>>> things in the boxes above. For Applications, there may be 0 to N for >>>> a given client. For Clients, you need at least 1. Does that make sense? >>>> >>> [Les:] Maybe you want to use "shadows" on the boxes to indicate there >> can be multiple Application boxes and multiple Client boxes? >>> What you say makes sense but I do not intuit that when I look at the ASSCII >> art. >>> >>>>> >>>>> >>>>> >>>>> Figure 1 >>>>> >>>>> >>>>> >>>>> Is the text "Op Data V" between I2RS Agent box and Routing System >>>>> box intentional? >>>> >>>> Yes. The 'V' is meant to be an arrow head pointed down. The request >>>> and data go from Client to Agent whereas the Response goes from Agent >>>> to Client. >>>> >>>> We are open to suggestions on how to make this clearer. >>> >>> [Les:] I think it would be clearer if you had two lines - one flowing down >> associated with the Op Data and one flowing up with the result. >>> >>>> >>>>> >>>>> >>>>> >>>>> Section 5.2 >>>>> >>>>> >>>>> >>>>> Secondary Identity >>>>> >>>>> >>>>> >>>>> This is defined to be "opaque" yet if not provided the agent is >>>>> supposed to insert "an UNAVAILABLE value". This seems to be a >>>>> contradiction unless we have a publicly defined value that clients >>>>> are prohibited from using. Absent that you would need a "Secondary >> Identity Valid" indicator. >>>> >>>> Good observation. I think it's fine to say that this field must be >>>> logged. If there is no application, then the field will be logged as >>>> empty. If there is an application, then whatever value is provided >>>> will be logged. >>>> >>>> Do you feel strongly that we need a field to indicate Application Present? >>>> >>> [Les:] I am fine w your changes. >>> >>> Les >>> >>>>> >>>>> >>>>> >>>>> Section 7.4 >>>>> >>>>> >>>>> >>>>> s/establish an vendor-agnostic/establish a vendor-agnostic >>>> >>>> Fixed. Thanks! >>>> >>>> Joe >
- [i2rs] RtgDir review: draft-ietf-i2rs-traceabilit… Les Ginsberg (ginsberg)
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Joe Clarke
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Alia Atlas
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Les Ginsberg (ginsberg)
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Joe Clarke
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Les Ginsberg (ginsberg)
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Joe Clarke
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Les Ginsberg (ginsberg)
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Joe Clarke
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Les Ginsberg (ginsberg)