[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: Delivery Notification <ipdvb@erg.abdn.ac.uk>

 Retrying

-----Original Message-----
From: "Postmaster" [mailto:"Postmaster";] 
Sent: Saturday, December 11, 2004 10:58 AM
To: "Undisclosed Recipient"
Subject: Delivery Notification <ipdvb@erg.abdn.ac.uk>

This is a delivery status notification, automatically generated by MTA
maildc2.nab.org on Sat, 11 Dec 2004 10:58:20 -0500 Regarding recipient(s) :
ipdvb@erg.abdn.ac.uk Delivery status : Failed. None of the mail servers for
the destination domain has so far responded. (erg.abdn.ac.uk).
We have been attempting delivery for 5 times.
Maximum delivery tries attempted. Please contact your administrator to
contact the destination domain or resend your message. Delivery failed.
Message Information: 
	Sender     : aallison@nab.org 
	Recipient  : ipdvb@erg.abdn.ac.uk 

MTA Response :4.4.1
The original message is included as attachment.

Attachment: ATT100174.TXT
Description: Binary data

--- Begin Message --- 
Please find comments below. There is a chance that I will be able to return
to the document and complete my review, but that may not happen. 

Broad issue - if the term being defined is in all caps, should not it be in
all caps when that defined term is used? Or a rule that only initial caps
are used after the all caps format should be pointed out. It is very bad to
attempt, and I believe this draft must not, normatively redefine any ISO/IEC
defined term. It may informatively list what another standard defines.

Quick scan - Need work on MPEG term usage; Section 7 scoping; Refs should be
updated from source web sited just b4 publications  (A/53 is now A/53C, for
example) 

MPEG term usage:

@PRIVATE SECTION. While  the use listed is one use, use of private sections
is NOT constrained to only service information. It may be used for any
Program data<a 13818-1 defined term>.  It is not accurate to assert that all
table sections must be carried over a single TS Logical Channel. Further
attempting to assert the rules for such sections is in appropriate as
13818-1 rules. The draft should say, informatively, something like "ISO-MPEG
requires that all table sections of a particular table _id must be carried
in packets identified with a single PID. A packets with a given PID may
contain data for more than one set of table sections.

@p10 TABLE SECTION.  Table sections are used for many purposes beside MPEG-2
SI. Users of MPEG-2 have added their own PSI[sic] table sections and
employer them for other purposed. Also there may be private table sections
that have any desired purpose. The point is they are related to any
particular MPEG Program, not the System Information. 

@p10 seem to be missing PDU definition.

@ p. 10, TS LOGICAL CHANNEL:  Add 'unique' to: "...All packets sent over a
TS Logical Channel carry the same unique PID value."   PID values are
required to be unique within each TS MULTIPLEX by MPEG-2 systems.

@ p10-11 TS MULTIPLEX:     Defining a TS MULTIPLEX in terms of the set of TS
logical channels is an interesting way to view it, but as there is an
internationally approved standard it would seem best to reference ISO/IEC
13818-1.  It is NOT limited to a common physical link. Common physical links
e.g., Ethernet, IEEE 1394, Satellite transponders can have more than one
MPEG-2 transport stream.  So the implication that the TS Logical Channel ID
is unique to a physical link is incorrect. The last sentence in the
definition is not wrong, but is not complete either. The same PID value can
identify MPEG-2 packets with totally unrelated content in different TS
MULTIPLEXes.

 @p11 Section 3. Asserting that ULE is limited to TS private streams seems
underspecified. What is the means of identifying that this private use of a
particular private stream_type is different from another's use of the same
stream_type?  It is a choice for the draft to be silent on how the PID value
with these datagrams is found, but is seems that use of the MRD should be
required in the PMT loop that has the private stream_type used by ULE.  All
programs must be listed per 13818-1, but that standard is silent on conflict
resolution among private users.   

@p12   Section 3, 4th para. It is interesting that this receiver behavior is
believed to be known. Particularly since the value 0xFF for table_id is
expressly forbidden by ISO-MPEG. The meaning asserted is simply wrong.
Padding (bytes of 0xFF) may occur in TS packets when a table section's
content ends before the end of the TS packet. When they occur the following
statements are correct.

@p12 last para. The use and meaning of adaptation field is completely
defined by ISO-MPEG. The assertion of its primary purpose does not appear
relevant or needed and I would not agree with the word 'primary' . The
assertion that values of 00 are discarded is interesting, and I would agree
with the speculation that they should be ignored and discard the packets.
The value '00' is not available for use, and discussion of anything but the
requirement that the value 01 is required here seems unneeded.

@p12 section 4. The sentence "Each SNDU is sent as a MPEG-2 Payload Unit."
can be expanded to read '"Each Subnetwork Date Unit is sent as a MPEG-2
Payload Unit." But Payload Unit is a defined term here, meaning a sequence
of bytes sent using a TS.  So all this sentence says is each sequence of
bytes is sent as a sequence of bytes.  Was something more intended?   It
would seem that the order of the bits in each byte should be specified as
well. MSBit first?

@p 12-13 Section 4.1  and 4.2. The D field is shown as a separate field in
figure 1 and then described as part of the Length field in the text. One can
deduce that the length field bits are sent divided over two bytes and that
the first byte has one bit that is unrelated to the length,  but the field
is not explicitly defined. The MSbyte is the one that has a bit that means
Destination Address present, and it is the first bit sent? The MSB of the
length field follows the D bit? Clarify.

 @section 4.4: bit order of the bytes in the field?

@Section 4.5 :I don't see the location of this filed. Does the destination
address field arrive just before the CRC? Section 4.1 says the D must be set
to 0, unless an End indicator, yet this section says is 1 may be used for a
non End Indicator situation. These sections need to be made consistent. What
is the non-default situation and when can that be used? Why say "by default"
in section 4.1?  The situations for not using the default should be stated,
if any exist.

@Section 4.6 "...represented 0x104C11DB7..." is opaque in meaning. What is
the ref for translating this and what does it mean?

 @Section 4.7 is this a receiver behavior spec section rather than a
description of format section ( as it seems to be)? The format meanings were
already specified..using slightly different words.

---far as I got---

Art Allison
Director, Advanced Engineering
NAB Science & Technology
1771 N St NW, Washington Dc 20036
202 429 5418 


-----Original Message-----
From: Gorry Fairhurst [  <mailto:gorry@erg.abdn.ac.uk>
mailto:gorry@erg.abdn.ac.uk]
Sent: Tuesday, November 30, 2004 4:47 PM
To: ipdvb@erg.abdn.ac.uk
Subject: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-03.txt


This note starts the WG two week Last-Call for comments for the WG document
named below:

draft-ietf-ipdvb-ule-03.txt

The Last-Call will end on 15/12/2004.

Members of the IETF ipdvb WG are asked to read the above draft and send any
issues, comments, or corrections to this mailing list. The WGLC procedure is
the last chance for this working group to modify/correct this document.

Please do forward any comments to the list.

Best wishes,

Gorry Fairhurst
(ipdvb WG Chair)

--- End Message ---