Forwarding and Control Element Separation (ForCES) Applicability Statement
draft-ietf-forces-applicability-09

Here is my AD review of your draft. Don't panic :-)

First: thanks for this document. I regard applicability documents
as a valuable part of the IETF document set and I am grateful to you
for your work in producing it.

Second: I am a bit of a bitch with document reviews! I tend to pick
up on a variety of nits as well as (rare) technical points. My
objective is to make the document's progression through IETF and IESG
reviews much smoother as well as reducing the load on reviewers and the
RFC Editor. I would also like your RFCs to be shiny and perfect.

So what follows are lot of nitty comments that I hope you can handle as
a simple set of updates. The comments are not mandates, so we can
discuss any of them.

Thanks,
Adrian

=========

idnits (http://tools.ietf.org/tools/idnits/) throws up some minor
issues you should fix before we go to IETF last call.

> idnits 2.12.04
>
> Checking boilerplate required by RFC 5378 and the IETF Trust (see
> http://trustee.ietf.org/license-info):
> -----------------------------------------------------------------
>
> == You're using the IETF Trust Provisions' Section 6.b License
>    Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec
>    2009.  (See http://trustee.ietf.org/license-info/)
>
> Checking references for intended status: Informational
> -----------------------------------------------------------------
>
> -- Looks like a reference, but probably isn't: '3' on line 135
>
> -- Looks like a reference, but probably isn't: '4' on line 135
>
> -- Looks like a reference, but probably isn't: '6' on line 449
>
> -- Looks like a reference, but probably isn't: '2' on line 442

I think these *are* intended to be references.

> == Missing Reference: 'RFC 3654' is mentioned on line 438, but
>    not defined

Need to take the space out of the citation in a couple of places

> == Unused Reference: 'RFC2629' is defined on line 511, but no
>    explicit reference was found in the text

You can probably delete this.

> == Unused Reference: 'RFC3654' is defined on line 514, but no
>    explicit reference was found in the text

Will be fixed by removing space from citation

> == Unused Reference: 'RFC3746' is defined on line 517, but no
>    explicit reference was found in the text

This really should be cited. Probably in the early sections of the I-D

> == Unused Reference: 'RFC3015' is defined on line 523, but no
>    explicit reference was found in the text

Surely not needed.

> == Unused Reference: 'RFC3292' is defined on line 527, but no
>    explicit reference was found in the text

Probably not needed.

> == Outdated reference: draft-ietf-forces-mib has been published
>    as RFC 5813
>
> == Outdated reference: draft-ietf-forces-model has been published
>    as RFC 5812
>
> == Outdated reference: draft-ietf-forces-protocol has been
>    published as RFC 5810

Update these three to show the new RFCs.

> -- Obsolete informational reference (is this intentional?):
>    RFC 3015 (Obsoleted by RFC 3525)

Probably goes away if you delete the unused reference.

=========

Section 4
s/low end/low-end/

=========

Section 4.1

Can you explain into which category configuration of ECMP function
falls?

=========

Dynamic key updates?
Security section or 4.1.1?

=========

Section 4.1.1

I found the terminology a bit broken here...

  Discovery is the process by which CEs and FEs learn of each other's
  existence.

  ForCES assumes that CEs and FEs already know sufficient
  information to begin communication in a secure manner.  The ForCES
  protocol is only applicable after CEs and FEs have found each other.
  ForCES makes no assumption about whether discovery was performed
  using a dynamic protocol or merely static configuration.

So I read this to mean that ForCES assumes that discovery has already
taken place before ForCES starts to exchange messages.

  During the discovery phase, CEs and FEs exchange capability
  information with each other.

But this cannot be the "discovery phase" because discovery has already
happened.

I see two possibilities...

1. If the ForCES RFCs already conflate "discovery" and "capability
  exchange", you need to make some changes like...

  OLD

    Discovery is the process by which CEs and FEs learn of each other's
    existence.

  NEW

    Discovery is the process by which CEs and FEs learn of each other's
    existence and exchange capabilities.

  and
  OLD

    ForCES makes no assumption about whether discovery was performed
    using a dynamic protocol or merely static configuration.

  NEW

    ForCES makes no assumption about whether CEs and PEs found out about
    each other using a dynamic protocol or merely static configuration.

2. Change

  OLD
                                                   
    During the discovery phase, CEs and FEs exchange capability
    information with each other.

  NEW

    During the capabilities exchange phase, CEs and FEs exchange
    capability information with each other.

=========

Section 4.1.2

  An
  implementation can choose its own method of topology discovery (for
  example use a standard topology discovery protocol like LLDP, BFD

I was not aware that BFD was a "standard topology discovery mechanism".
In fact, to quote from RFC 5880 Section 3.1: "there is no discovery
mechanism in BFD."

Maybe you would like to list OSPF and LMP instead?

In any case, you should provide Informational References for the
examples you quote.

=========

Section 4.1.5

Currently this is headed "QoS Exchange" but I think you mean "QoS
Capabilities Exchange and Configuration"

=========

Section 5

I think that, since Section 4.1.6 allows the configuration and reporting
of FE-FE security, Section 5 needs to explain that the CE-FE Security
MUST be at least as good as the desired FE-FE security.

This probably also applies to the functions that can be configured in
Section 4.1.7.

=========

Section 6

  From one perspective, it is a single network element;

There is some ambiguity about the subject of this sentence. What is
"it"?

=========

Section 6.1

Please express "RFC 3654" as a citation.

s/As an example, router/As an example, a router/

I think this section is fine and accurate. Would it be worth explaining,
however, that commands at a management interface to the NE will arrive
at the CE and may require ForCES interactions between CE and FE to
complete. This may impact the atomicity of such commands and may require
careful implementation by the CE.

=========

Section 6.1 and 6.2

Please capitalise the section headers.

=========

Section 6.2

  As with all IETF protocols a MIB is
  provided for the purposes of managing the protocol.


1. s/MIB/MIB module/

2. I don't think this statement is true. Why not simply say:
  "A MIB module is provided for the purposes of managing the
  protocol."

3. Can you insert a forward reference to Section 6.3?

=========

Section 6.3

s/MIB/MIB module/ throughout

  The ForCES MIB [I-D.ietf-forces-mib] is a primarily read-only MIB

"primarily"? There is no writeable or even creatable object in the
ForCES MIB module.

=========

Section 6.3.1

s/from a element/from an element/

=========

This proto write up is for the document "ForCES Applicability
Statement"
[http://datatracker.ietf.org/doc/draft-ietf-forces-applicability]

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

The Document Shepherd is Jamal Hadi Salim .
This document has been sitting around for some time being held up
by need to first publish ForCES protocol(RFC 5810) and model(RFC5812)
documents. It  has evolved from its initial publication to match the
current view of the two RFCs.
The shepherd has personally reviewed the document and believes it is
ready for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The draft has been well-discussed by key WG members and key non-WG
members on the ForCES mailing list and at the IETF meetings.
The Document Shepherd feels the breadth of the reviews that have
been performed were sufficient.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No - there are no concerns that the document require additional
broader review.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The document shepherd is not aware of specific concerns or issues with this
document.
The document shepherd does not believe there are any IPR concerns/disclosures
to this document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is strong working group consensus behind this document.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

The shepherd is not aware of any discontent related to this document.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.


There are a few well-known minor nits that the shepherd believes can
be resolved by the RFC editor. Example, the document still references
draft-ietf-forces-protocol instead of its published identity:
RFC 5810.


  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document Shepherd believes all references are appropriately split.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

This document has no IANA actions

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no known outstanding technical or editorial issues related to the
above issues.
  Technical Summary

      This document describes the applicability of the ForCES architecture,
      model and protocol.  It provides example deployment scenarios and
      functionality where ForCES could be applied.

  Working Group Summary

      There is consensus in the WG to publish this document.

  Document Quality

      The document has been reviewed by the ForCES WG.

  Personnel

    Jamal Hadi Salim is the document shepherd and Adrian Farrel is the
    responsible Area Director.