Last Call Review of draft-ietf-forces-lfb-subsidiary-management-01

Request Review of draft-ietf-forces-lfb-subsidiary-management
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-08-28
Requested 2015-08-03
Draft last updated 2015-09-01
Completed reviews Secdir Last Call review of -01 by Alexey Melnikov (diff)
Opsdir Last Call review of -01 by Jürgen Schönwälder (diff)
Opsdir Telechat review of -02 by Jürgen Schönwälder
Assignment Reviewer Jürgen Schönwälder
State Completed
Review review-ietf-forces-lfb-subsidiary-management-01-opsdir-lc-schoenwaelder-2015-09-01
Reviewed rev. 01 (document currently at 02)
Review result Not Ready
Review completed: 2015-09-01



I have reviewed draft-ietf-forces-lfb-subsidiary-management-01 as part
of the Operational directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

I believe the document is 'Not Ready' for publication.

Disclaimer: I am not a FORCES expert and hence I am not aware of all
the related work and terminology (and time constraints prevent me from
reading all the relevant RFCs). So there is a reasonable chance that I
am simply missing too much background. But then I also think that it
is desirable that RFCs explain the problem being addressed in such a
way that other computer networking people can understand which problem
is being addressed.

- What is Fr in Figure 1? This is not expanded anywhere. I also do not
  understand how Figure 1 helps to explain where the 'SM LFB control'
  happens. Is the Control Application talking Ff to the FEs? This is
  how I read the text but this is not what I see in Figure 1. Since I
  have trouble to understand section 1, my understanding of the rest
  of the document may be misguided - so I apologize if this is the

- It would help a lot if there would be a more concrete example. It
  remains unclear to me what a 'Control Application' (located in a
  ForCES Network Element) is, an illustrative example would help me a
  lot to better understand the problem being addressed by the
  document. The use cases discussed in section 2 do not help me to
  understand things. I note that text in section 2 talks about 'CE
  management application' or a "CE system manager' - are these all
  'Control Applications' in the sense of Figure 1? And are they really
  restricted to a single ForCES element as indicated by Figure 1?

- Section 3 talks about 'SM class' - where is that class defined? Is
  that a synonym for something called differently in the rest of the

- The document talks about 'config' or 'configuration' and I wonder
  what the authors really mean with this term or how it is scoped.  I
  am aware that these terms are used in various different meanings in
  different parts of the IETF. I guess the authors have a much more
  narrow scope in mind than for example people in the OPS area working
  on NETCONF technology. At least this is what I infer from this

    Experience has shown that a generic attribute name-value pair is
    useful for describing config information.

  If the scope is not narrow, then I might question the above
  statement.  Perhaps it helps if the term 'configuration' is more
  clearly defined.  Since there are no examples for attributes, it
  remains unclear what the authors really had in mind.


- s/be be/be/

Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <