Last Call Review of draft-ietf-forces-lfb-subsidiary-management-01
review-ietf-forces-lfb-subsidiary-management-01-opsdir-lc-schoenwaelder-2015-09-01-00

Hi,

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

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

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

    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.

Editorial:

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

http://www.jacobs-university.de/

>