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