SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol
draft-ietf-forces-sctptml-08

[Ballot discuss]
Section 6. IANA considerations

The proposed and individual registered ports seems to be in conflict with registration policy. Although RFC 4960 doesn't say so explicitly from below quotes it can be inferred that SCTP ports should not be registered on port numbers that for other protocols already are in use, due to existing TCP, DCCP or UDP applications interest in using SCTP in the future.

RFC 4960 says:

  o  A port name registered for TCP MAY be registered for SCTP as well.
      Any such registration SHOULD use the same port number as the
      existing TCP registration.

  o  Concrete intent to use a port SHOULD precede port registration.
      For example, existing TCP ports SHOULD NOT be registered in
      advance of any intent to use those ports for SCTP.

I think we should avoid creating these potential conflicts on ports 6701 and 6702. I would suggest that IANA revoke the current SCTP registrations on port 6700, 6701 and 6702 and assign new ports to SCTP ML.

[Ballot comment]
9.2.  Informative References

  [FE-MODEL]
              Halpern, J. and J. Hadi Salim, "ForCES Forwarding Element
              Model", October 2008.

  [FE-PROTO]
              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.

[Ballot comment]
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 4.2.1.1. 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 4.2.1.1? Just to be clear, I do agree with it.

[Ballot comment]
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 4.2.2.5 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.

[Ballot discuss]
The DISCUSS and COMMENT is largely based on the OPS-DIR review performed by Juergen Quittek which was not answered by the authors:

1. I am missing a statement on how ForCES messages are encoded in SCTP messages. Even if this is done straightforward, i.e.
each message is transferred as payload of a single SCTP packet, this should be explicitly mentioned. May there be a need for distributing a single message over several SCTP packets?
May several messages be sent in a single SCTP packet?
In the appendix you address this step of processing in figure 8 calling it "Format msg." and "decapsulate". But also here it does not become clear what "formatting" and "decapsulating" mean.
This should be explicitly discussed by the document. Maybe I missed it when reading the draft, but if not, please clarify.

2. In Figure 7 there is a message from the CE TML to the FE TML.
According to the figure, this message is not related to any corresponding ForCES message. How would this message be encoded in an interoperable way? Which document defines the encoding?
Please provide a normative reference to it.

3. Section 4.2.2.3 states that "By using 3 sockets in conjunction with the partial-reliability feature, both timeliness and prioritization can be achieved.".
I have two comments on this sentence:
  - You say "can be achieved". This is not sufficient.
    I would read it as "Can be achieved, but typically are not"
  - Why does the choice of three sockets provide prioritization?
      - The SCTP stack may block packets on the high priority
        socket because it processes packets on the low priority
        socket. You need to argue here that you use SCTP
        prioritization and that the SCTP stack specification
        (please refer to normative reference) requires all
        compliant implementations to handle priorities as
        required by [FE-PROTO].
      - Prioritization of different SCTP sockets is not dealt
        with at routers between FE and CE. Why do you think
        that at these routers low priority packets would not
        block high priority packets? Or if they did, why would
        you still meet the requirements of [FE-PROTO]?

4. In section 7.1.1, second paragraph you state: "It should be straightforward to extend such a policy to alternatively use the
3 SCTP TML port numbers as SPD selectors.  But as noted above this choice will require increased number of SPD entries."
" It should be straightforward ..." is a speculation that does not seem to be appropriate in a standards track RFC. What if it is not straightforward? Maybe you rather want to say:
"Implementors MAY extend such a poliy to ...".

5. In section 4.2.1.5 the second sentence is "The LP channel is processed only if a channel that is higher priority than itself has no more messages left to process." This is not correct. If one channel with higher priority has no more message, there still may be another one that has a message. Suggestion:
"The LP channel is processed only if there is no channel with higher priority that has one or more messages left to process."

6. In appendix B.1, the last lines on page 25 include "On success ... a success indication is presented to the TML".
I think it is not the TML but the PL to which the indication is presented.

7. The first section of appendix B.3 says: "The TML is agnostic to the nature of the PL message it delivers to the remote TML".
This in in contradiction to the first line of the next paragraph
saying: "When the FE PL sends a message to the TML, the TML is expected to pick one of HP/MP/LP channels and send out the ForCES message". Choosing the appropriate channel and priority for a message is not what I would call "being agnostic to the nature of the message".

[Ballot comment]
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?

---

Section 4.2.1.2

  it is strongly recommended

Is that '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.)

===

Nits

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
  [FE-PROTO]

s/draft/specification/

---

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.

s/draft/document/

---

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.

[Ballot discuss]
I found this an interesting and readable document, but I have a number
of concerns. These are largely editorial rather than technical, so it
should be possible to resolve them relatively easily.

---

I don't understand how [FE-PROTO] is not a normative reference.

---

Section 3.2.1

  There are two interfaces to the PL and TML, both of which are out of
  scope for ForCES.

I don't undesrtand this. This is a ForCES working group document. If
these interfaces are out of scope, why are they described here, and why
is Appendix B present?

The "TML API" is also mentioned in Section 4.2

---

Section 4.2.1

There are some 'MUST' statements about the priority levels on each of
the channels, and which channels each message must use. What happens if
an implementation violates this?                                               

---

Section 4.2.1.5

Is this scheduling description actually essential for correct
interoperability, or is this just advice for how to make a nice
implementation? It is true that an implementation that follows a
different scheduling algorithm might become congested and not be able
to deliver the right ForCES messages, but isn't that a broken
implementation rather than a non-conformant implementation?

I would prefer this scheduling description to move to the Appendix with
the other information about scheduling.

---

Section 9.2

Seem to be missing some publication information for [SCTP-API]. Is this
an I-D or an RFC? If so, what is its name/number?

[Ballot comment]
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.

[Ballot comment]
Section 4.2.2.6., 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 4.2.1.5) 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.

[Ballot discuss]
Section 4.2.1.5., paragraph 0:
> 4.2.1.5.  Scheduling of The 3 Channels

  DISCUSS: You're not getting strict prioritization by using three
  sockets, even if a sender gives transmission priority to HP over MP
  and LP and a receiver first serves all requests queued up in the HP
  buffer before going on to the MP and LP channels. That's because there
  is no *transmission* prioritization between the three streams. In
  other words, a sender can enqueue enough MP and LP messages to delay
  transmission/reception (and hence processing) of HP messages - SCTP
  will not preempt transmission of queued MP and LP data when new HP
  data shows up; all transmissions will occur in parallel. I want to
  make sure that this is clear and will not cause issues for FORCES
  before I clear the discuss.

IANA comments:

IANA has the following comments on draft-ietf-forces-sctptml-06.txt:

The document requests the following assignments:

A) SCTP ports 6700, 6701 and 6702 have been registered at
http://www.iana.org/assignments/port-numbers

frc-hp 6700/sctp ForCES HP (High Priority) channel
frc-mp 6701/sctp ForCES MP (Medium Priority) channel
frc-lp 6702/sctp ForCES LP (Low priority) channel

Upon approval, IANA will replace the current references for these
port numbers with references to this document.

B) SCTP Payload Protocol ID (PPID) values of 21, 22, and 23
have been registered at
http://www.iana.org/assignments/sctp-parameters

Value SCTP Payload Protocol Identifier Reference Date Assigned
----- -------------------------------- ----------- -------------

21 ForCES-HP [draft-ietf-forces-sctptml] 2009-08-04
22 ForCES-MP [draft-ietf-forces-sctptml] 2009-08-04
23 ForCES-LP [draft-ietf-forces-sctptml] 2009-08-04

These references will be updated when the document is approved.

This proto write up is for document "SCTP based TML
(Transport Mapping Layer) for ForCES protocol"
[draft-ietf-forces-sctptml-06]

  (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 ForCES working group co-chair
Jamal Hadi Salim . Jamal is also a co-author of
this document.  He has personally reviewed the document and
believes it is ready for forwarding to the IESG for publication.
The 3 documents that form the core output work done by the
ForCES WG have a dependency on this document and are awaiting its
publication. These docs are:
1) ForCES Forwarding Element Model (draft-ietf-forces-model-16)
2) ForCES Protocol Specification (draft-ietf-forces-protocol-22)
3) ForCES MIB (draft-ietf-forces-mib-10)


  (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 well-discussed by key WG members and key non-WG members
on the ForCES mailing list and at the IETF meetings.
Michael Tuxen and Randy Stewart (SCTP gurus) have reviewed it from an
SCTP point of view.
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 require 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.
The document shepherd does not believe there are any IPR concerns/disclosures
to this document.

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

There is strong working group consensus behind this document. It is
an effort of several years work.
An interop in July 2009 between 3 different implementations by WG participant
utilizing draft version 4 was successful. In addition, there are two
different extensions to public domain traffic sniffers (ethereal and tcpdump)
by 2 other WG participants.

  (1.f)  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
          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?

The shepherd has utilized the tools and ID checklist and there are no
known nits.

  (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].

The document Shepherd believes all references are appropriately split.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration 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 Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA considerations are correct. The authors have already reserved
the ports and SCTP IDs specified in the draft and chose the names of
the registry in consensus with IANA and SCTP experts (Michael Tuxen).

  (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.

This proto write up is for document "SCTP based TML
(Transport Mapping Layer) for ForCES protocol"
[draft-ietf-forces-sctptml-06]

  (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 ForCES working group co-chair
Jamal Hadi Salim . Jamal is also a co-author of
this document.  He has personally reviewed the document and
believes it is ready for forwarding to the IESG for publication.
The 3 documents that form the core output work done by the
ForCES WG have a dependency on this document and are awaiting its
publication. These docs are:
1) ForCES Forwarding Element Model (draft-ietf-forces-model-16)
2) ForCES Protocol Specification (draft-ietf-forces-protocol-22)
3) ForCES MIB (draft-ietf-forces-mib-10)


  (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 well-discussed by key WG members and key non-WG members
on the ForCES mailing list and at the IETF meetings.
Michael Tuxen (SCTP guru) has reviewed it from an SCTP point of
view.
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 require 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.
The document shepherd does not believe there are any IPR concerns/disclosures
to this document.

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

There is strong working group consensus behind this document. It is
an effort of several years work.
An interop in July 2009 between 3 different implementations by WG participant
utilizing draft version 4 was successful. In addition, there are two
different extensions to public domain traffic sniffers (ethereal and tcpdump)
by 2 other WG participants.

  (1.f)  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
          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?

The shepherd has utilized the tools and ID checklist and there are no
known nits.

  (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].

The document Shepherd believes all references are appropriately split.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration 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 Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA considerations are correct. The authors have already reserved
the ports and SCTP IDs specified in the draft and chose the names of
the registry in consensus with IANA and SCTP experts (Michael Tuxen).

  (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.