[i2rs] Rtg Area QA Review: draft-ietf-i2rs-ephemeral-state-02

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 10 October 2015 21:03 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1221C1A916B for <i2rs@ietfa.amsl.com>; Sat, 10 Oct 2015 14:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0b9JplumDbYM for <i2rs@ietfa.amsl.com>; Sat, 10 Oct 2015 14:03:30 -0700 (PDT)
Received: from mxb2.tigertech.net (mxb2.tigertech.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8071A914C for <i2rs@ietf.org>; Sat, 10 Oct 2015 14:03:30 -0700 (PDT)
Received: from localhost (localhost []) by mailb2.tigertech.net (Postfix) with ESMTP id 9D2FA580002; Sat, 10 Oct 2015 14:03:30 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2782F1C02C3; Sat, 10 Oct 2015 14:03:30 -0700 (PDT)
To: "i2rs@ietf.org" <i2rs@ietf.org>, Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, 'Jon Hudson' <jon.hudson@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <56197D21.3090304@joelhalpern.com>
Date: Sat, 10 Oct 2015 17:03:29 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/Jgv2VbvbUjZHUuAUMm2tiAqyKyc>
Subject: [i2rs] Rtg Area QA Review: draft-ietf-i2rs-ephemeral-state-02
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: <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: Sat, 10 Oct 2015 21:03:32 -0000

For details on Routing Area QA reviews, see: 

Name: draft-ietf-i2rs-ephemeral-state-02
     I2RS Ephemeral State Requirements
Reviewer: Joel M. Halpern
Review Date: October 10, 2015

This document is close to ready for working group last call.

Major issues: None.

Minor Issues:
     I would suggest that the introduction needs to include a 
description, longer than that in the abstract, of the purpose of the 

     If the document purpose is as stated in the abstract, to provide 
requirements to NetConf and NetMod working groups regarding ephemeral 
state, then section 2 should have a bit more explanatory text, as the 
requirements there are explicitly not abotu ephemeral state.  It may be 
as simple as stating that these requirements are repeated hear to 
provide context for the reader.  Or whatever explanation does apply for 
why they are here.

     On section 3.2 requirement 02, the text prohibiting reference from 
non-ephemeral to ephemeral state needs some clarification.  First, it 
should be clear that this is a requirement on behavior outside of I2RS, 
as I2RS can not refer to non-ephemeral state.  Also, it seems likely 
that such incorrect references could be attempted at either model 
definition time or NetConf request application time.  As such 
"validation error" may be too specific a description of the errors needed.

     Requirement 3.4 is written as if writeable / non-writeable were a 
new requirement to NetConf.  I believe what is wanted here is only that 
there must be indications in the model of ephemeral elements, and that 
it is writeable.  If there is a need for non-writeable ephemeral 
elements, that should be described seperately.  At this reading, I do 
not see a need for such.

     Section 3.6 would benefit from an introductory sentence indicating 
that these requirements are included because they have an impact on 
viable solutions to the ephemeral state requirements, although they 
themselves are more general requirements applying to I2RS operations.

     Given that the design team is looking at a model which they 
describe as a limited panes of glass model, it seems that if section 4 
is retained (as it provides useful context) section 4.2 needs to be 
modified to be clear as to what solution is being rejected.

Editorial Issues:  Not noted