IETF Logo Mail Archive

[RTG-DIR] RtgDir review: draft-ietf-i2rs-traceability-08

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 27 April 2016 21:39 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D72312D57D; Wed, 27 Apr 2016 14:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level:
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-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 tWBvCgM9oBuL; Wed, 27 Apr 2016 14:39:42 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B8312D553; Wed, 27 Apr 2016 14:39:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13608; q=dns/txt; s=iport; t=1461793181; x=1463002781; h=from:to:cc:subject:date:message-id:mime-version; bh=XvXNWhIH7z9oo/n/NUSuJIUxstndcetu803WATTggb4=; b=MkaJ/TMQuVKm24lgdDPCqvPSpJ/fJgeCAYbI40+hHcHBHyGhczJ0+RYh j3XisgzXoPMMeOGNM49AOeG+DxdfP8cyIDFhEveQoguYEoCNQBxwXNPVF cgeQodiacVqhc5qyE+Z5JCn8s2+PohnZaKGVxn9KrWOZHtWxcCATflB6p A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C+AgANMSFX/5tdJa1VCYJsTFN9AQW0c4RzAQ2BdiKFbYE6OBQBAQEBAQEBZRwLhEgtTBIBGgJkFw8BBA4NiCIOwjkBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGIYUeFNgWYEAGFe4gUgW5Og3+IXY8vAQ8PAQFCg2ttiDZ/AQEB
X-IronPort-AV: E=Sophos;i="5.24,543,1454976000"; d="scan'208,217";a="265083969"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 21:39:40 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3RLddZU018932 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 21:39:39 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 16:39:39 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Wed, 27 Apr 2016 16:39:39 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "rtg-ads@ietf.org" <rtg-ads@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-i2rs-traceability-08
Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQ==
Date: Wed, 27 Apr 2016 21:39:39 +0000
Message-ID: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.14.223]
Content-Type: multipart/alternative; boundary="_000_5afaa922862d4b4a9dc67f117ae5366aXCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/d1aCC5PT-cFizgqKIOFt1FtkdQE>
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: [RTG-DIR] RtgDir review: draft-ietf-i2rs-traceability-08
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2016 21:39:44 -0000

Hello,



I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.



Document: draft-ietf-i2rs-traceability<https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/>

Reviewer: Les Ginsberg

Review Date: April 27, 2016

IETF LC End Date: April 29, 2016

Intended Status: Informational



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.



Major Issues: None



Minor Issues:



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.



Along with this an additional timestamp - Processing Initiated - would be useful to indicate when processing of the request actually began.



Nits:



Section 5.1



s/Some notable elements on the architecture/ Some notable elements of the architecture



Figure 1



Not clear to me why Application IDs start at 0 but Client IDs start at 1.



Figure 1



Is the text "Op Data V" between I2RS Agent box and Routing System box intentional?



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.



Section 7.4



s/establish an vendor-agnostic/establish a vendor-agnostic

v2.23.0 | Report a Bug | By Email