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

Joel: 

Thank you for the review.  I complete an revision to address these issues. 

Sue 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Saturday, October 10, 2015 5:03 PM
To: i2rs@ietf.org; Jonathan Hardwick; 'Jon Hudson'
Subject: [i2rs] Rtg Area QA Review: draft-ietf-i2rs-ephemeral-state-02

For details on Routing Area QA reviews, see: 
https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

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 document.

     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

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs