Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-17.txt

From: [email-masked]
Date: Tue, 20 Sep 2016 11:08:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to the Routing System of the IETF.

        Title           : I2RS Ephemeral State Requirements
        Authors         : Jeff Haas
                          Susan Hares
	Filename        : draft-ietf-i2rs-ephemeral-state-17.txt
	Pages           : 11
	Date            : 2016-09-20

Abstract:
   The I2RS (interface to routing system) Architecture document
   (RFC7920) abstractly describes a number of requirements for ephemeral
   state (in terms of capabilities and behaviors) which any protocol
   suite attempting to meet I2RS needs has to provide.  This document
   describes in detail requirements for ephemeral state for those
   implementing the I2RS higher-protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-17

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Joe Clarke <[email-masked]>
Date: Tue, 20 Sep 2016 14:54:14 -0400

>    implementing the I2RS higher-protocol.

I have found some issues in this document.  See:

https://www.marcuscom.com/draft-ietf-i2rs-ephemeral-state-17.txt-from-.diff.html

XML diff is attached.

Joe
--- draft-ietf-i2rs-ephemeral-state-17.xml	2016-09-20 14:06:28.000000000 -0400
+++ /home/jclarke/src/draft-ietf-i2rs-ephemeral-state-17.xml	2016-09-20 14:48:00.428510000 -0400
@@ -38,7 +38,7 @@
 <?rfc subcompact="no" ?>
 <?rfc iprnotified="no" ?>
 <?rfc strict="no" ?>
-<rfc category="std" docName="draft-ietf-i2rs-ephemeral-state-17"  ipr="trust200902">
+<rfc category="info" docName="draft-ietf-i2rs-ephemeral-state-17"  ipr="trust200902">
   <front>
     <title abbrev="I2RS Ephemeral State Requirements">I2RS Ephemeral State Requirements </title>
 
@@ -125,7 +125,7 @@
 	 sections 3-6 to clarify requirements discussed by the I2RS and NETCONF working groups. 
 	 Section 7 provided additional requirements that detail how write-conflicts 
 	 should be resolved if two I2RS client write the same data. 
-	 Section 8 details an additional requirement that details on I2RS support 
+	 Section 8 details an additional requirement that describes I2RS support 
 	 of multiple message transactions.
 	 Section 9 highlights two requirements in the I2RS publication/subscription requirements
 	 <xref target="RFC7923"></xref> that must be expanded for 
@@ -187,7 +187,7 @@ service the valid uses of a non-secure t
 </section>
 <section title="Ephemeral State Requirements"> 
 <t>
-In requirements Ephemeral-REQ-01 to Ephemeral-15, Ephemeral state 
+In requirements Ephemeral-REQ-01 to Ephemeral-REQ-15, Ephemeral state 
 is defined as potentially including in a data model 
 ephemeral configuration and operational state which is flagged as 
 ephemeral. 
@@ -213,13 +213,13 @@ ephemeral. 
      short lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB.
 	 Ephemeral state constraints should be assessed when the ephemeral 
 	state is written, and if any of the constraints change to make the constraints invalid
-	after that time the I2RS agent should notify the I2RS client. 
+	after that time the I2RS agent SHOULD notify the I2RS client. 
       </t>
 	  
    <t>Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-ephemeral state 
    as a constraint. Non-ephemeral state can be configuration state or operational state. 
    </t>
-   <t>Ephemeral-REQ-05: I2RS pub-sub <xref target="RFC7923"></xref>, tracing (<xref target="RFC7922"></xref>, 
+   <t>Ephemeral-REQ-05: I2RS pub-sub <xref target="RFC7923"></xref>, tracing <xref target="RFC7922"></xref>, 
    RPC or other mechanisms may lead to undesirable 
    or unsustainable resource consumption on a system implementing an I2RS agent.
    It is RECOMMENDED that mechanisms be made available to permit 
@@ -340,10 +340,9 @@ defined in section 7 below in requiremen
    ephemeral state. I2RS protocol MUST NOT mandate the internal mechanism for how AAA protocols 
    (E.g. Radius or Diameter) or mechanisms distribute priority per identity except that
    any AAA protocols MUST operate over a secure transport layer (See Radius <xref target="RFC6614"></xref>
-   and Diameter <xref target="RFC6733"></xref>. 
-   distribute  priority per identity. 
+   and Diameter <xref target="RFC6733"></xref>). 
    
-   Mechanisms which prevent collisions of
+   Mechanisms that prevent collisions of
    two clients trying to modify the same node of data are the focus.  
    
    </t>
@@ -435,7 +434,7 @@ inserted into the I2RS ephemeral state.
 		<t>Juergen Schoenwaelder,</t>
 		<t>Kent Watsen,</t>
 		<t>Robert Wilton, and</t>
-		<t>Joe Clark,</t>
+		<t>Joe Clarke</t>
 	    </list>
 	</t>
 </section>
@@ -458,4 +457,4 @@ inserted into the I2RS ephemeral state.
 	  &I-D.hares-i2rs-protocol-strawman;
     </references>
   </back>
-</rfc>
\ No newline at end of file
+</rfc>