Forwarding and Control Element Separation (ForCES) Implementation Experience
draft-haleplidis-forces-implementation-experience-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2011-06-28
|
03 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-06-27
|
03 | (System) | IANA Action state changed to No IC from In Progress |
2011-06-27
|
03 | (System) | IANA Action state changed to In Progress |
2011-06-24
|
03 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-06-24
|
03 | Amy Vezza | IESG has approved the document |
2011-06-24
|
03 | Amy Vezza | Closed "Approve" ballot |
2011-06-23
|
03 | Adrian Farrel | Approval announcement text changed |
2011-06-23
|
03 | Adrian Farrel | Approval announcement text regenerated |
2011-06-23
|
03 | Adrian Farrel | Ballot writeup text changed |
2011-06-23
|
03 | (System) | New version available: draft-haleplidis-forces-implementation-experience-03.txt |
2011-05-26
|
03 | Cindy Morgan | Removed from agenda for telechat |
2011-05-26
|
03 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation. |
2011-05-26
|
03 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-26
|
03 | Ralph Droms | [Ballot comment] In this text: 3.3. Model The model inherently is very dynamic. What "model"? The Forces data model? More generally, I agree with … [Ballot comment] In this text: 3.3. Model The model inherently is very dynamic. What "model"? The Forces data model? More generally, I agree with Jari's comment about the content of the document. I learned a little about potential issues in implementing the struct component (but no details). Are there any other major implementation issues aside from struct components and handling protocol messages? |
2011-05-26
|
03 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-26
|
03 | Jari Arkko | [Ballot comment] 2. NAT issues. ForCES can be deployed everywhere and can run over SCTP/IP. In order for the FE and CE … [Ballot comment] 2. NAT issues. ForCES can be deployed everywhere and can run over SCTP/IP. In order for the FE and CE to work behind NATs you must ensure that the TML ports are forwarded and that the firewall allows SCTP through. This seems to be mixing NAT and firewall issues. Clearly, support NATs requires for those NATs to be capable of handling SCTP traffic to begin with. In addition, firewalls may have to be configured to let the traffic through. I found Section 3.3 very hard to understand for someone who is not closely familiar with the Forces technology. I don't understand why we need sections that talk about very generic topics, like 3.4.2 that describes how to decode a protocol message. And maybe more generally, I'm not sure what I learned from this document in terms of real forces implementation experience. Where are the difficult areas? Is the spec broken in places? Are there interoperability problems? Is further work needed in some issue? |
2011-05-26
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-26
|
03 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-25
|
03 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-25
|
03 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-24
|
03 | Russ Housley | [Ballot comment] The Gen-ART Review by Francis Dupont on 9-May-2011 suggested several editorial changes. Please consider them. |
2011-05-24
|
03 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-24
|
03 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-23
|
03 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-23
|
03 | Stewart Bryant | [Ballot comment] Developers of ForCES FEs and CEs should take the security considerations of the Forwarding and Control Element Separation Framework [RFC3746 … |
2011-05-23
|
03 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-23
|
03 | Stephen Farrell | [Ballot comment] s/difficulty lie/difficulty lies/ |
2011-05-23
|
03 | Stephen Farrell | [Ballot discuss] This should be an easy discuss to clear, probably via an RFC editor note, if anything at all is needed. Is the optional … [Ballot discuss] This should be an easy discuss to clear, probably via an RFC editor note, if anything at all is needed. Is the optional KeyInfo TLV used for a cryptographic key? (Sorry, reviewing offline;-) If so, are there any special implementation concerns that have arisen? For example, sometimes, in high security environments, one has to handle key values in special memory. If that might applu but the details are not currently known (e.g. if no-one has tried to do a high assurance implementation) then just saying so in the security considerations would be fine and I'd clear on that basis. |
2011-05-23
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-05
|
03 | Adrian Farrel | Telechat date has been changed to 2011-05-26 from 2011-05-12 |
2011-05-03
|
03 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-05-03
|
03 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-04-21
|
03 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2011-04-21
|
03 | Adrian Farrel | Ballot has been issued |
2011-04-21
|
03 | Adrian Farrel | Created "Approve" ballot |
2011-04-21
|
03 | Adrian Farrel | Placed on agenda for telechat - 2011-05-12 |
2011-04-11
|
03 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2011-04-06
|
03 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Rob Austein |
2011-04-06
|
03 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Rob Austein |
2011-04-05
|
03 | Amy Vezza | Last call sent |
2011-04-05
|
03 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (ForCES Implementation Experience Draft) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'ForCES Implementation Experience Draft' as an 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 2011-05-03. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-haleplidis-forces-implementation-experience/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-haleplidis-forces-implementation-experience/ |
2011-04-05
|
03 | Adrian Farrel | Last Call was requested |
2011-04-05
|
03 | Adrian Farrel | State changed to Last Call Requested from Publication Requested. |
2011-04-05
|
03 | Adrian Farrel | Last Call text changed |
2011-04-05
|
03 | (System) | Ballot writeup text was added |
2011-04-05
|
03 | (System) | Last call text was added |
2011-04-05
|
03 | (System) | Ballot approval text was added |
2011-04-05
|
03 | Adrian Farrel | Ballot writeup text changed |
2011-04-05
|
03 | Adrian Farrel | Proto Write-up This proto write up is for the document "ForCES Implementation Experience" draft-haleplidis-forces-implementation-experience (1.a) Who is the Document Shepherd for this document? Has the … Proto Write-up This proto write up is for the document "ForCES Implementation Experience" draft-haleplidis-forces-implementation-experience (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 Adrian Farrel . 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 presented and been discussed on the ForCES mailing list and at IETF meetings. The WG does not object to the publication of this document, but feels it falls outside the core interests of the WG. 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 requires 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. No IPR has been disclosed, and the document shepherd is not aware of any IPR concerns. (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? This is not a working group submission. There is no objection from any member of the WG. The WG understands the contents of the document. The WG does not object to the publication of this document, but feels it falls outside the core interests of the WG. (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. No nits. No formal sections needing review. (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]. 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. (1.k) Technical Summary This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol. Working Group Summary The document has been presented and discussed in the WG and there has been no disagreement in the WG for the publication of this draft from any WG member. It was initially submitted as a WG document but was eventually suggested by the WG to be an individual submission because it feels that the document falls outside the core interests of the WG. Document Quality This is an Informational I-D. The document has been reviewed by the ForCES WG. Personnel Adrian Farrel (adrian.farrel@huawei.com) is the document shepherd and the responsible Area Director. |
2011-04-05
|
03 | Adrian Farrel | Draft added in state Publication Requested |
2011-04-05
|
03 | Adrian Farrel | [Note]: 'AD Sponosred Submission for publication as an Informational RFC' added |
2011-01-10
|
02 | (System) | New version available: draft-haleplidis-forces-implementation-experience-02.txt |
2010-09-01
|
01 | (System) | New version available: draft-haleplidis-forces-implementation-experience-01.txt |
2010-05-12
|
00 | (System) | New version available: draft-haleplidis-forces-implementation-experience-00.txt |