I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document:  draft-ietf-teas-gmpls-resource-sharing-proc-07
Reviewer:  Dale R. Worley
Review Date:  23 Jan 2017
IETF LC End Date:  17 Jan 2017
IESG Telechat date:  2 Feb 2017

Summary:

       This draft is basically ready for publication, but has nits
       that should be fixed before publication.

There remain a few editorial items:

2. Conventions Used in This Document	
		
    The reader is assumed to be familiar with the terminology in	
    [RFC3209], [RFC3473], [RFC4872], [RFC4873] and [RFC4427].	
		
That is a significant help to the reader, but it's also rather
intimidating!  Is there a way to point out that 4427 is specific to
recovery?

3.1.1.  1+R Restoration

   Unlike a protecting LSP which is set up before the failure, a
   restoration LSP is set up per need basis, after the failure.

Probably better to change "per need basis" to "when needed".

3.2. Resource Sharing By Restoration LSP	
			
"By" generally should not be capitalized in titles, as it is a
preposition.

                               +-----+      +-----+
                               |  F  +------+  G  +--------+
                               +--+--+      +-----+        |
                                  |                        |
                                  |                        |
        +-----+    +-----+     +--+--+      +-----+     +--+--+
        |  A  +----+  B  +-----+  C  +--X---+  D  +-----+  E  |
        +-----+    +-----+     +-----+      +-----+     +-----+

          Figure 3: Resource Sharing in 1+R Recovery Scheme


   [...]  Nodes A and B
   reconfigure the resources to set up the restoration LSP by sending
   cross-connection command to the data plane.

   In the recovery scheme employing revertive behavior, after the
   failure is repaired, the resources on nodes A and B need to be
   reconfigured to set up the working LSP.  The traffic is then reverted
   back to the original working LSP.  

It's not clear to me why nodes A and B are reconfigured and/or do the
reconfiguring.  Any "global" reconfiguring would be driven by the
head-end A alone, I think.  Any "local" reconfiguring would be done by
C and possibly E.  Though perhaps there is reconfiguring that must be
done along the entire path, but that would be attributed to A, B, C,
F, G, and E together.  I suspect there is a trivial editorial error
here...

[END]