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 |