Skip to main content

Implementation Report for Forwarding and Control Element Separation (ForCES)
draft-ietf-forces-implementation-report-02

Revision differences

Document history

Date Rev. By Action
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2010-08-17
02 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-08-16
02 (System) IANA Action state changed to No IC from In Progress
2010-08-16
02 (System) IANA Action state changed to In Progress
2010-08-16
02 Cindy Morgan IESG state changed to Approved-announcement sent
2010-08-16
02 Cindy Morgan IESG has approved the document
2010-08-16
02 Cindy Morgan Closed "Approve" ballot
2010-08-13
02 (System) Removed from agenda for telechat - 2010-08-12
2010-08-12
02 Cindy Morgan State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Cindy Morgan
2010-08-12
02 (System) [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by IESG Secretary
2010-08-11
02 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-08-11
02 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2010-08-11
02 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner
2010-08-11
02 Tim Polk
[Ballot comment]
I support Dan's discuss.  To my reading, two interoperable implementations of the security features are needed
to fully satisfy the requirements for Draft …
[Ballot comment]
I support Dan's discuss.  To my reading, two interoperable implementations of the security features are needed
to fully satisfy the requirements for Draft Standard specified in 2026.  The requirements were loosened in 5652
(see section 6.2) but I do not think there would be IETF consensus to support an exception case for *all* the
security features. 

At a minimum, I know one Security AD that would object... :) 

The simplest solution would be to remove the first sentence in section 3.  Creating and demonstrating the
interoperability of two implementations of the security features would more difficult but more rewarding.
2010-08-11
02 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-08-11
02 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-08-10
02 Peter Saint-Andre
[Ballot comment]
This is a fine document. Thank you for completing interoperability testing and for documenting the results!

One nit: several acronyms are not expanded …
[Ballot comment]
This is a fine document. Thank you for completing interoperability testing and for documenting the results!

One nit: several acronyms are not expanded on first use (e.g., "PL" and "XML").
2010-08-10
02 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre
2010-08-10
02 Dan Romascanu
[Ballot discuss]
The following issue is based on an observation made by Pekka Savola in his OPS-DIR report.

In Section 3 (Summary) the following statement …
[Ballot discuss]
The following issue is based on an observation made by Pekka Savola in his OPS-DIR report.

In Section 3 (Summary) the following statement is being made:

>  The authors attest that the ForCES Protocol, Model and SCTP-TML meet
  the requirements for Draft Standard.

However, Sections 5, 6.1.3.3 and 9 indicate that the (mandatory) SCTP-TML IPsec security framework was not implemented by any of the tested implementations and thus not tested for interoperability. I believe that the text in the Summary section needs to reflect this situation.
2010-08-10
02 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2010-08-04
02 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-07-13
02 Adrian Farrel State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Adrian Farrel
2010-07-13
02 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2010-07-13
02 Adrian Farrel Ballot has been issued by Adrian Farrel
2010-07-13
02 Adrian Farrel Created "Approve" ballot
2010-07-13
02 Adrian Farrel Placed on agenda for telechat - 2010-08-12 by Adrian Farrel
2010-07-12
02 Amanda Baber IANA comments:

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2010-07-12
02 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-06-29
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alan DeKok
2010-06-29
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alan DeKok
2010-06-28
02 Amy Vezza Last call sent
2010-06-28
02 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-06-27
02 Adrian Farrel Last Call was requested by Adrian Farrel
2010-06-27
02 Adrian Farrel State Changes to Last Call Requested from AD Evaluation::AD Followup by Adrian Farrel
2010-06-27
02 (System) Ballot writeup text was added
2010-06-27
02 (System) Last call text was added
2010-06-27
02 (System) Ballot approval text was added
2010-06-27
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-06-27
02 (System) New version available: draft-ietf-forces-implementation-report-02.txt
2010-06-06
02 Adrian Farrel State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Adrian Farrel
2010-06-06
02 Adrian Farrel
I have done a review of your draft as the responsible AD who will take it through the IETF last call and IESG review.

This …
I have done a review of your draft as the responsible AD who will take it through the IETF last call and IESG review.

This is a great document and a real help both in determining the stability of the protocol specifications and understanding the interest in the work. Thanks for your efforts.

Listed below you will find a number of relatively small points that I would like you to work on before we take the document forward. Most are editorial, but a couple ask for you to add a sentence of two by way of explanation.

Nothing here is mandatory - everything is open for discussion.

Cheers,
Adrian

=========

idnits (http://tools.ietf.org/tools/idnits/) shows some issues that
should be fixed before this I-D goes to the IETF and IESG for review.

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
> ----------------------------------------------------------------
>
> == Unused Reference: 'RFC2629' is defined on line 1326, but no
>    explicit reference was found in the text
>
> == Unused Reference: 'RFC3552' is defined on line 1329, but no
>    explicit reference was found in the text
>
> == Unused Reference: 'RFC5226' is defined on line 1340, but no
>    explicit reference was found in the text

Suggest deleting these three references

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

Update these three references to show the RFCs

=========

Section 2.3

s/MUST IMPLEMENT/MUST implement/

=========

Section 3

I do not believe that it is necessary to remove the statement on being
ready for Draft Standard. However, I appreciate the note in the write-
up that suggests that the WG is not ready to suggest advancing the
protocol spec. Indeed, we seem to be lacking some deployment experience
that I think the IESG would look for, and it will be worth letting the
implementations mature through the addition of the features not yet
implemented at the time of this document.

No need for any change to the document.

=========

Section 3

  There were no notable difficulties in the interoperability test and
  almost all issues were code bugs that were dealt with mostly on site
  and tests repeated successfully.

I think a forward reference to section 6.2.3 would be helpful.

=========

Section 5

  The mandated TML security requirement, IPSec, was not validated
  during the interop and is not discussed in this document.  Since
  IPSec is well known and is widely deployed not testing in presence of
  IPSec does not invalidate the tests done.

Actually, there is another small mention of IPSec in Section 6.1.3.3.
Given that this is "the mandated TML security requirement", I think it
is worth drawing this out by adding the following note...

  Note that Section 6.1.3.3 indicates that none of the implementations
  reporting included support for IPSec, but all indicated their
  intention to implement.

I also think that you should include some text in section 9 to say that
no security elements of the protocol specifications were tested, and
that the survey indicated that no security elements had yet been
implemented.

=========

Section 6.2.3

I think there are three clarifications I would like to see.

For issue #1

        This has been corrected by changing
        the word recommended to MUST in the SCTP-TML document regarding
        priority channel messaging.

- Can you please include a reference for the document
- I am assuming that the test was done before the publication of "the
  document" as an RFC so that the change was benign. Maybe you can say
  "...before it was published as an RFC"

For issue #3

        This was caused by network problems.

- Can you add a clarification as to why this does not need any fix to
  the protocol specifications, for example with enhanced retransmission.

For issue #10

        This was a SCTP issue.  SCTP-PR was needed to be used.

- Can you say why this is not a protocol spec issue that SCTP-PR needs
  to be mandated, or guidance added on when to use it. Perhaps this
  can be covered here with a heads-up like the one you put in issue #8.

=========

It would be nice, although not essential, to report on the manageability
implementations. But only if this information exists.

=========
2010-06-06
02 Adrian Farrel State Changes to AD Evaluation from Publication Requested by Adrian Farrel
2010-05-21
02 Cindy Morgan [Note]: 'Joel Halpern (jmh@joelhalpern.com) is the Document Shepherd.' added by Cindy Morgan
2010-05-21
02 Cindy Morgan
(1.a) Joel Halpern is the Document Shepherd for this document.
> I have reviewed this document personally, and I believe
> it is ready for …
(1.a) Joel Halpern is the Document Shepherd for this document.
> I have reviewed this document personally, and I believe
> it is ready for forwarding to the EISG for publication as
> an Informational RFC.
>
> (1.b) More than sufficient review was performed by the working
> group. The document accurately and usefully describes
> the implementation adn interoperability experience.
>
> (1.c) I do not believe that the document needs significant broader
> reviewer.
>
> (1.d) I have no concerns with the content of the document.
> It should be noted that although written as qualification
> for advancing the ForCES material on the standards track,
> we are not yet requesting such advancement, as other kinds
> of experience, particularly in the modeling aspects of the
> work, will also be useful. If desired, we can remove the
> one reference currently in the text to document advancement.
>
> (1.e) The working group supports this document.
>
> (1.f) No appeal or other complaint about this document has been
> mentioned, to the best of my knowledge.
>
> (1.g) The document gets no errors from ID-Nits, and as far as I
> know meets all other formal requirements for publication.
>
> (1.h) References are properly split, and there are no downward
> references. (The normative references will need to be
> replaced by the RFC Editor during processing with the
> proper RFC references, as all the referenced I-Ds have
> been published as RFCs.)
>
> (1.i) As an implementation report, this document makes no
> requests of IANA, and the IANA considerations section says
> that.
>
> (1.j) There is no formal language usage that requires
> verification in this document.
>
> (1.k) 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 describes three implementations of the ForCES
> protocol, and an extensive interoperability test event that
> was done using those three implementations.
>
> Working Group Summary
> The working group was very pleased with the results of this
> testing, and the availability of these implementations.
>
> Document Quality
> The document is clear, readable, and informative
2010-05-21
02 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2010-02-25
01 (System) New version available: draft-ietf-forces-implementation-report-01.txt
2009-09-07
00 (System) New version available: draft-ietf-forces-implementation-report-00.txt