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

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:yaakov_s@rad.com]
> Sent: Sunday, August 10, 2008 3:34 PM
> To: l2tpext@ietf.org; 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
L2tpext@ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext