Interoperability Report for Forwarding and Control Element Separation (ForCES)
RFC 6984

[Ballot comment]

abstract: >2 years to write this up? wow. Did
something go wrong somewhere? Or, if this is just a
case of "we didn't bother becuase the wg were doing
other more important work" then saying so would be
good.

[Ballot comment]
No objection to the publication of this draft, just curious about a couple of things:

0) People often get the certificate bit wrong, was there any thought to including the test certificates that you used in this document?

1) There's two versions of IKE; did you implement IKEv1 or IKEv2?  RFC 5811 points to IKEv1 interestingly enough, which was obsoleted by RFC 4036 (and that was obsoleted by RFC 5996).

2) ESP can be implemented in RFC 4303 without using any of the ESP v3 features and then it looks just like ESP v2.  Were any of the v3 features implemented (i.e., which version of ESP was implemented)?

3) I take it from the list that the ESP encryption was not implemented?

4) One of the requirements in RFC 5811 is that cryptographic agility be supported.  Did you test this SHOULD:

  A compliant implementation SHOULD provide operational means for
  configuring the CE and FE to negotiate other cipher suites and even
  use manual keying.

5) Did you test any of the SAD and SPD setups?

one nit: IPSec and IPsec are both used should just be IPsec.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-forces-interop-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Interoperability Report for Forwarding and Control Element Separation (ForCES)) to Informational RFC


The IESG has received a request from the Forwarding and Control Element
Separation WG (forces) to consider the following document:
- 'Interoperability Report for Forwarding and Control Element Separation
  (ForCES)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document captures results of the second Forwarding and Control
  Element Separation (ForCES) interoperability test which took place on
  February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang
  Gongshang University, China.  RFC 6053 reported the results of the
  first ForCES interoperability test, and this document updates RFC
  6053 by providing further interoperability results.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-forces-interop/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-forces-interop/ballot/


No IPR declarations have been submitted directly on this I-D.

AD review
=====

Hi authors of draft-ietf-forces-interop,

I have done my usual AD review of your document as part of processing
the publication request. The intention of the review is to catch issues
that might show up in IETF last call or IESG review and thereby
improve the efficiency of those review stages.

There are a few small issues that I would like you to address with a
new revision. As always, my comments are open for discussion and
disagreement.

I have placed the document into "Revised I-D Needed" state in the
datatracker until we resolve these small points.

Thanks for the work,
Adrian

---

I believe the intention of this work is to provide supplementary
information on top of that already contained in RFC 6053. In view of
that, you are correct to state that this document updates RFC 6053. To
achieve that smoothly you need to:

- Add a piece of metadata to the top of the file to read:

Updates: 6053 (if approved)

  (see http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ for an
  example)

- Explain the update in the Abstract. I'd suggest...

  RFC 6053 reported the results of the first ForCES interoperability
  test, and this document updates RFC 6053 by providing further
  interoperability results.

The additional context to the update that you give in the Introduction
is perfect.

---

I am worried by the references to two I-Ds. [I-D.ietf-forces-lfb-lib]
and [I-D.ietf-forces-ceha] were I-Ds at the time of testing.  There is
no law against this, but it gives us a problem:

The versions tested need to be pinned in time. For example,
draft-ietf-forces-lfb-lib will probably be published as an RFC before
your document becomes an RFC, but it would not be correct to say that
you tested that RFC. So, I think you need some text talking about the
draft versions tested and giving specific name to the drafts rather than
just pointing at the citation.

I can probably help you draft some text here, but I think that it would
be quickest for you to try to write down what you tested, and then I can
polish it.

---

The references are all to pot! idnits shows this up clearly and you need
to fix this before the draft can go forward.

(The uses of IP addresses flagged by idnits are OK and do not need to be
changed.)

---

The use of RFC 2119 language is a problem and needs to be fixed.

You are not defining protocol behavior in this document and do not need
section 2.1 at all.

Then you need to go through the document and clean up the upper case. If
you are making a direct quote from another RFC, then please make it much
clearer using indentation, quote marks, and by saying
  "As stated in [RFC1234]:"

If you are not quoting, then you really can use lower case. But please
be careful even then. What would it mean to say "An implementation must
do this"? Would it really be the case that you mean: "We tested to see
whether an implementation does this as required in section 1.2 or
[RFC1234]"?

---

I have a personal dislike of repeated definitions copied from other
documents. They can cause all sorts of fun if you make a mistake when
you copy the text!  So I would prefer section 2.2. simply to point at
the definitions from other RFCs.

However, I think this is a matter of style, and I do not insist that
you make this change.

---

Section 3.1 says:

  Some errata related to ForCES document were found by the
  interoperability test.  The errata has been reported to related IETF
  RFCs.

This is great. IMHO it is a more valuable outcome than the rest of the
work :-) If you can find a way to briefly list these or provide pointers
to the errata reports, I think this would be really nice and would help
validate all your hard work.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

This document is a Informational document. It describes a set of tests
that were run, for the information of the community.  The intended
status is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up.
Recent examples can be found in the "Action" announcements for
approved documents. The approval announcement contains the following
sections:

Technical Summary:
This document captures test results from the second Forwarding and
control Element Separation (ForCES) interoperability test which took
place on February 24-25, 2011 in the Internet Technology Lab (ITL) of
Zhejiang Gongshang University, China.

Working Group Summary:
The Working Group reviewed the document, and is happy with the
contents.  The test participants feel it accurately reflects the
interoperability tests.

Document Quality:
This document provides a clear description of the testing
arrangements, the interoperability tests that were run, and the
results of those tests.

Personnel:
Joel Halpern is the Document Shepherd. Adrian Farrel is
the Responsible Area Director.

(3) Briefly describe the review of this document that was performed
by the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has adequately reviewed the document and thinks that it's
ready for publication.  It has also been presented to te working group.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document shepherd is confident that the docuent has been reviewed
sufficiently by the working group fo clarity and relevance.  It as it
was written by the test participats, it accurately reflects the
testing that took place.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

As the document is a description of an interoperability test of the
ForCES protocol, the ForCES WG provided the necessary technical skills
for te review.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

The shepherd has no concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed. If not, explain why?

The authors have confirmed that all known IPR has been disclosed.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There is no IPR declared.

(9) 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?

The WG consensus is very supportive of the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There have been no threats of appeal, nor any milder expressions of
unhappiness within or outside of the WG relative t thi document.

11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to
be thorough.

There were some nits relative to references that can be fixed during
editing.

The ID-NITS tool also complains about the IP Addresses in the
document, which are the actual IP Addresses used in the test.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

The document does not require any formal reviews, as it does not have
material subject to the formal review procedures.

(13) Have all references within this document been identified as either
normative or informative?

Yes. All references are properly separated and labelled.

(14) 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 plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part
of the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This documet updates RFC 6053.  This is noted in the Abstract and
Introduction.  As it does not change the status of RFC 053, that is
not currently included in the title bar material.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all protocol extensions that the document
makes are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

No IANA considerations are needed.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

No IANA considerations are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No such sections exist in the document.