Re: [Fwd: WG Last Call: draft-ietf-l2tpext-tdm-05]

Yaakov Stein <[email protected]> Sun, 10 Aug 2008 15:34:25 +0300
Newsgroups gmane.ietf.l2tpext
Message-ID <[email protected]>
In general, this ID looks ready for publication.

I spotted a few minor nits (some of which are just for readability):


  Encapsulation of the xxx TDM PWs over L2TPv3 is described in
SHOULD BE
  Encapsulation of xxx TDM for L2TPv3 is described in
[It is not the PW which is encapsulated ...]


   Tearing down of session for a TDM pseudowire is identical to
   [RFC3931].
SHOULD BE
   Tearing down of session for a TDM pseudowire is performed as described in [RFC3931].
[This is simple a special case, not something different that happens to be identical]


  Its usage for all types of TDM PWs implies the following semantics:
SHOULD BE
  Its usage for all types of TDM PWs employs the following semantics:


   Note: For structure-agnostic T1 emulation the values 24 and 25 do not
SHOULD BE
   Note: For structure-agnostic T1 emulation, the values 24 and 25 do not


   The Payload Bytes field contains the value that represents the number of the TDM Payload bytes
SHOULD BE
   The Payload Bytes field contains a value representing the number of TDM Payload bytes


  4) Set to '00' for all TDM PWs (both CESoPSN and SAToP) that do
     not use signaling packets.
SHOULD BE
  4) Set to '00' for SAToP PWs and for CESoPSN PWs not using separate signaling packets.


   PT is the payload type expected in the RTP header.  Value of zero
   indicates that the payload type will not be checked to detect
   malformed packets.
SHOULD BE
   PT is the payload type expected in the RTP header.  A value of zero
   instructs the receiver not to check payloads for malformed packets.
[I am sure that this wording can be improved, but it is clearer than the original.]

   Timestamp Clock Frequency is the clock frequency used for the time
   stamping in 8 KHz.
SHOULD BE
   Timestamp Clock Frequency is the clock frequency used for the time
   stamping in units of 8 KHz.


   SSRC indicates the expected value of SSRC ID in the RTP header.  A
   zero in this field means that SSRC ID will not be used for detecting
   misconnections. Since L2TP provides an alternative security mechanism
   using cookies, if the cookie length is larger than zero the SSRC
   SHOULD be zero.
QUESTION: Does that mean you use different SSRC values when
two different PWs have their source TDM traceable to the same clock?

The first paragraph in section 3 needs some English language work
(missing articles, "if it exist" -> "if one exists", etc.)


   4.    If one side cannot send RTP header requested
SHOULD BE
  4.    If one side cannot send an RTP header as requested


  If CESoPSN basic NxDS0 PW is extended to support CE application
 signaling in a separate PW instance, then the two PW instances:
DO YOU MEAN
   If CE signaling is transported in a separate PW instance, then the two PW instances:
[I assume that you don't mean that you are waiting for the IETF to extend CESoPSN]


teh -> the


   Any values that are Reserved or unassigned in this specification are
   assignable by Expert Review [RFC5226].
NOT CLEAR - required values will be assigned now by the expert in charge.
expert review is for allocation of new registry values.


  [PWE3-TDM-CTR]
SHOULD BE
  [RFC 5287]


Y(J)S