Time Division Multiplexing over IP (TDMoIP)
draft-ietf-pwe3-tdmoip-06

 From discussion between Gen-ART reviewer Joel Halpern and Yakov Stein:

The introduction does not tell me what this document is
about.  A few sentences along the lines of the technical summary in
the tracker would help.

[YJS] The description is in the Abstract and hinted at in the first
paragraph
of the Introducton. I will add a few sentences to the first paragraph
to make this more clear.

-----------

The paragraph on SAToP in section 2.seems to characterize a
loss rate of one fifth of one percent as an "extremely reliable and
overprovisioned PSN."  While I do not want to get in to an argument
about what is acceptable, it is to be noted that even TCP will have
performance problems with a link with a 0.2% loss rate.  ISPs with
loss rates much lower than that are still not usually referred to as
"extremely reliable."  I would recommend simply removing the sentence.

[YJS] This number come up from two sources.
1) documents presented to the ITU question that worked in parallel
to PWE3 showing that this is indeed a kind of dividing line between
well-engineered networks and best-effort ones.
2) empirical results that the user experience of circuit emulation
with AIS substitiution drops at this level (see
draft-stein-pwe3-tdm-packetloss-01.txt
now expired).
In any case, we are continually asked to characterize when to
stop using SAToP and go over to one of the structure-aware methods.
This is as good a break-point as any.
For these reasons I would suggest keeping this sentence.

BC: I disagree. It's almost as though people working in the ITU
are wishing to characterize the Internet as horribly unreliable,
but that can't be true can it? Better to simply drop the
specific percentage, I think.

The statement about customary practice is to operate jitter buffer half full would lead to much larger voice latency that would be needed in most cases. I would like to talk to authors on what they mean by this - perhaps we are just talking past each other but as it is, it does not seem correct.

This document should be consistent with the requirements and architecture defined in RFC3916 and RFC4197. RFC3916 includes in Section 6 a statement that 'Each PWE3 approach SHOULD provide some mechanisms for network operators to manage the emulated service' and then goes into more detailed requirements about how such mechanisms could be implemented. I am surprised about the lack of any managemement or operational considerations section in this document in order to show how the requirements in Section 6 of RFC3916 are supposed to be addressed.

  The document seems to lack a both a reference to RFC 2119 and the
  recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
  keywords.

  Why is this going for Informational?

Section 4.1:

   UDP Checksum (16 bits) is the checksum of UDP/IP header and data.  If
      not computed it must be set to zero.

Does there exist any other error checking of the packet? If not I would strongly recommend against setting the checksum to 0.