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

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 10 Aug 2008 18:53:08 +0300

Yaakov,
Lots of thanks for catching the nits.
I see your comments as editorial, and I shall accommodate them in the post-LC revision of the draft.

Regards,
        Sasha

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Sunday, August 10, 2008 3:34 PM
> To: [email-masked]; Alexander Vainshtein
> Cc: Carlos Pignataro; Stewart Bryant
> Subject: RE: [Fwd: [L2tpext] WG Last Call: draft-ietf-l2tpext-tdm-05]
>
>
> 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
>
>
>
_______________________________________________
L2tpext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l2tpext

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 10 Aug 2008 15:34:25 +0300

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]

   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.

[I am sure that this wording can be improved, but it is clearer than the original.]

   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?

  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