[i2rs] Shepherd review on draft-ietf-i2rs-architecture-06

Mach Chen <mach.chen@huawei.com> Thu, 04 December 2014 03:22 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8694C1A002F for <i2rs@ietfa.amsl.com>; Wed, 3 Dec 2014 19:22:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 PScpMXOyMmih for <i2rs@ietfa.amsl.com>; Wed, 3 Dec 2014 19:22:53 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A18F1A000D for <i2rs@ietf.org>; Wed, 3 Dec 2014 19:22:53 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMI64973; Thu, 04 Dec 2014 03:22:51 +0000 (GMT)
Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Dec 2014 03:22:51 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.51]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Thu, 4 Dec 2014 11:22:44 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "draft-ietf-i2rs-architecture@tools.ietf.org" <draft-ietf-i2rs-architecture@tools.ietf.org>
Thread-Topic: Shepherd review on draft-ietf-i2rs-architecture-06
Thread-Index: AdAPcZAjBj8H2Vo1SnSKKyPqx6sNiw==
Date: Thu, 04 Dec 2014 03:22:43 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B2E50A8@SZXEMA510-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/zabssB9WTqCz9He-Ms5Yc0D5oj8
Cc: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: [i2rs] Shepherd review on draft-ietf-i2rs-architecture-06
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 04 Dec 2014 03:22:56 -0000

Hi Authors,

I just finished the shepherd review on draft-ietf-i2rs-architecture-06, it's well written and easy for reading. I have the following comments for this version, most of them are editorial comments. 

1.
Some (not well-known) of the acronyms may need to be expanded in their first use. For example, DCCP, etc.

2. 
The architecture document raises a lot of requirements to I2RS protocol, Information model, Data model. It somehow can be treated as a requirement document. But I only found that there is only one place that uses the RFC2119 language and no reference to RFC2119 (idnits tool also pointed this). Do we need to use the RFC2219 language for all requirements or just change only one place to non-RFC2119 usage?

3.
Section 1.2 the last third paragraph

"..., these these error cases should be
   resolved by the network applications and management systems."

There is a redundant "these".

4.
Section 6.1

"To facilitate operations, deployment and troubleshooting, it is
   important that traceability of the I2RS Agent's requests and actions
   be supported via a common data model."

Seems it's better to make a reference to draft-clarke-i2rs-traceability here.

5.
Section 6.2.1

"The I2RS Agent Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all
      its cached I2RS Clients."

There is a redundant "Agent".

6.
Section 6.2.3

"An I2RS Agent may decide that some state should no longer be applied.
   An I2RS Client may instruct an Agent to remove state it has applied.
   In all such cases, the state will revert to what it would have been
   without the I2RS; that state is generally whatever was specified via
   the CLI, NETCONF, SNMP, etc."

An I2RS can only withdraws its own states that have been applied to the specific Routing Element, there may be other I2RS clients are in effect. So the decription "the state will revert to what it would have been without the I2RS" may not be accuracy. How about changing it as:
"...the state will revert to what it would have been without the I2RS Client; that state is generally whatever was specified via the CLI, NETCONF, SN, MP, other I2RS Clients etc."

7.
Section 6.4.1

"...per-interface."  This..."

There is a redundant " in between. 

s/per-platform-/per-platform

8.
Section 6.4.5.4

Should the editors' note be removed before sending to IESG review?


9.
Section 7.8

s/it be possible/it is possible

Hope this useful!

Best regards,
Mach