SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol
RFC 5811

Note: This ballot was opened for revision 08 and is now closed.

(Ross Callon) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2009-11-03)
No email
send info
Section, paragraph 1:
>    The architecture of this TML defines three separate channels, one per
>    socket, to be used within any FE-CE setup.  The scheduling design for
>    processing the TML channels (Section is strict priority.  A
>    fundamental desire of the strict prioritization is to ensure that
>    more important work always gets node resources such as CPU and
>    bandwidth over lesser important work.

  See above; the current scheme doesn't really result in this.

(Pasi Eronen) (was Discuss) No Objection

Comment (2009-11-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The reference for IKEv1 should be to RFC 2409, not 4109 (which is
just a list of algorithms, not the protocol itself).

(Adrian Farrel) (was Discuss) No Objection

Comment (2009-11-17)
No email
send info
Always a shame that I-D nits doesn't pass cleanly.


Section 1

I may be being over-sensitive, but it seems odd to me that TCP is not
listed in the set of examples in the definition of ForCES Protocol 
Transport Mapping Layer.


Section 4

We all love SCTP, but is this document the right place to describe it?



   it is strongly recommended



Section 6
The IANA section could really use a little extra meat.
I see that IANA has worked out what to do, but it would not hurt to
name the registries and show the specific allocations. (Text not unlike
that in IANA's last call evaluation.)



Shouldn't include citations in the Abstract. 


Section 1
   ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
   architecture that defines the ForCES protocol architecture and the
   state transfer mechanisms as defined in [FE-PROTO].
The layer defines the architecture?                                        
Or the layer is part of the architecture.


Section 3

   The ForCES protocol layering constitutes two pieces: the PL and TML
   layer.  This is depicted in Figure 1.

I think the 'L' in PL and TML stands for 'layer'.

Section 3

   There is some content overlap between the ForCES protocol draft



Section 3.1
   by the IETF [FE-PROTO].  The PL level is responsible for associating
Now it is the "layer level"? :-)

Ditto 3.2
   The TML level

Etc. throughout the document.


Section 8
   discussions that have made this draft better.



Section 3.2.1

   Figure 2 also shows an interface referred to as CEM/FEM[RFC3746]

This use of "also" confused me. The previous paragraph talks about two
interfaces. This is not a third intercace.

(Russ Housley) No Objection

Comment (2009-11-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  The Gen-ART Review by Avshalom Houri provided editorial suggestions,
  and the author said they would be included in a future revision.  A
  revision has not been posted yet.

(Cullen Jennings) No Objection

Comment (2009-11-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think SCTP is a fine protocol for Forces to use and have no fundamental objection to this specification. Few small comments 

Note I am not in agreement with the statement

   SCTP is also very mature and widely used making it a good choice for
   ubiquitous deployment.

One of the normally quoted advantages of SCTP is no HOL blocking. I was fascinated to read I've actually pointed this out to some of the authors / proponents of SCTP before and they violently disagree with me. Do they agree with section Just to be clear, I do agree with it.

(Alexey Melnikov) No Objection

Comment (2009-11-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
9.2.  Informative References

              Halpern, J. and J. Hadi Salim, "ForCES Forwarding Element
              Model", October 2008.

              Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J.,
              Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R.
              Gopal, "ForCES Protocol Specification", November 2008.

Are these suppose to point to drafts?
If not, RFC numbers are missing.

(Tim Polk) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2009-11-18)
No email
send info
1. An Abstract section should not include references

2.. In section 3.1, last but one line you use the acronym LFB.
Please explain what it refers to.

3. Section is titled "Satisfying HA Requirement". Please explain acronym "HA".

4.In section 7, the last but one line before section 7.1 you write "([FE-PROTO])". I would remove "(" and ")".

5. In appendix A the last word on page 21 is "discuss". I think it should be "discusses".

6. in appendix A.2, last two lines I would replace "The implementor is left to ..." with "It is left to the implementor to ...".

7. Appendix B, first two lines: Please replace "provides" by "discusses", "outlines", "describes", "defines", "specifies", or another word that is more appropriate.

8. Appendix B, lines 4-5: "The implementer is expected to worry about details ...". A standards track document should not request an implementer to "worry" :-) Please replace "worry about" with another phrase, for example, "take care about".  

9. Some times you use "implementer", some times you use "implementor". Both words are fine. But it would be nice if you decide for one form of this term and use only this one.

10. Appendix B, enumerated item 2, first line:
"Sending and reception" -> "Sending and receiving"

11. Appendix B, figure 7: Please label the message from CE TML to FE TML. All other messages are labeled, but this one is not.

12. The complete IANA considerations section consists of one
sentence: "This document makes request of IANA to reserve SCTP ports 6700, 6701, and 6702.  This document also requests for SCTP PPID 21, 22, and 23." I think that usually IANA needs more information for creating these entries in their registries. In 4.2.1 there is text which explains what each value means which should be reflected here, so that IANA knows exactly what each port value and PPOD means.

13. [FE-MODEL] and [FE-PROTO] are still Internet-Drafts. If they are approved as RFCs then the RFC number needs to be mentioned, if not the last I-D and marked as work-in-progress

14. I support Adrian Farrel's portion of the DISCUSS about [FE-PROTO] needing to be a normative reference.

Magnus Westerlund (was Discuss) No Objection