[L2tpext] draft-ieft-l2tpext-tdm-02.txt review

[Ignacio Goyret <[e-mail]>]

Hi,
Just a few minor details:
1) In section 2.1, in regards to the "Bit Rate" field, it reads:

    "Bit Rate is defined in [PWE3-IANA]. Its usage for all types of TDM
     PWs assumes the following semantics: 
     1. This interface parameter MAY be omitted, if the attachment circuit 
         bit-rate is unambiguously derived from the PW Type."

  Does this mean that the "Bit Rate" field can be omitted from the AVP?
  If so, how can you tell that this field is omitted but "Payload Bytes"
  is not?
  If that's not the case, the phrase needs to be rewritten to avoid confusions.
  May be a simple solution is to replace these paragraphs with something
  like this:

      "Bit Rate is defined in [PWE3-IANA]. Typically, it is expressed
       as the number of DS0 channels in the corresponding attachment
       circuit."

   Or even better:

      "Bit Rate is defined in [PWE3-IANA]."

2) There are similar issues on the definition of "Payload Bytes".
   For example, the term "payload type" is used in semantic #1.
   semantic number 2b probably needs to be rephrased to make it easier
   to parse and understand.

3) Why do you need the R bit in the TDM PW AVP? Why is the presence of
   the RTP AVP not sufficient to indicate presence of an RTP header?

4) If the T bit is not used, remove the description and indicate that
   the bit in the AVP is reserved. No need to carry leftovers :-)

5) Can you rephrase the description of the F bit? It is very confusing
   with the double negatives.

6) On the RTP AVP, the description of the D-bit is a bit confusing and
   leaves a few cases to be discussed. When can differential mode be used?
   Only if both sides send RTP AVPs with the D-bit set? What happens if
   one side sends an RTP AVP with the D-bit set and the other side sends
   an RTP AVP but with the D-bit cleared?

   BTW, you will need a better description of what does it mean "differential
   mode" or a reference to another document that describes it.

7) On section 2.2 (RTP AVP), am I correct in assuming that the C-bit
   refers to how the data is presented in the data channel?
   If so, may I suggest a small rewrite like this (between <add> and </add>)?
     "The C bit indicates the ordering of the RTP header and the control
      word <add>on the data channel</add>:"

   I haven't verified this, but is the order of the headers defined in detail
   in the drafts mentioned? If not, you would do a great service by adding a
   couple of drawings showing the sequence of headers.

8) To help IANA and the rfc-editor, you may want to consider replacing
   all "TBD" and "TBA" with unique strings as the ones you used in the
   IANA considerations section.

9) Section 3 reads:
     "...If the peer agrees with the CESoPSN AVP it will send an appropriate
      ICRP..."

    What is the "CESoPSN" AVP? It is not defined on this draft and there
    is no external reference. Can you clarify?


BTW, idnits reports a minor detail:

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 8 pages

Cheers,
-Ignacio Goyret


_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext