RE: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE

["Allison, Art" <AAllison@nab.org>]

This is getting very close:
Comment 1
The revised language about TS mapping at the end of section 1 is much
appreciated and a valuable addition; but overreached a bit in the last
sentence. The last sentence before section 2 is:
"Addressing and mapping issues for IP over MPEG-2 are described in
[draft-ipdvb-ar]. " 

I suggest this should say:
"Addressing and mapping issues for ULE over MPEG-2 are also described in
[draft-ipdvb-ar]." 

Reasons:
A) <ULE vs. IP> There are other means for sending IP over MPEG-2 (e.g.,
those that are in daily operation in the US per ATSC standards, and
undoubtly per other standards in other countries). Draft-ipdvb-ar does not
attempt to cover all other standards bodies' approaches to sending IP over
MPEG-2, but rather just ULE, and narrowing the above statement to just ULE
removes the potential for false impressions. 
B) <also> The word 'also' was inserted as draft-ipdvb-ar will supplement not
replace the ISO standards.

Comment 2
I don't think the declarative sentence about Byte order after the definition
of Byte is in the optimal location (but since I do not suggest an
alternative location, I do not object to it being there). I leave it to the
commenter to measure if it is an adequate change to address the comment
about the need to define Byte order. 

Comment 3
In the new definition for 'ULE Stream' I think the last ULE is redundant and
the prediction of what will be done elsewhere too strong. Revise last
sentence to read: "ULE Streams may be identified by definition of a
stream_type in SI/PSI [ISO_MPEG2]."
Reason: This change avoids prejudging what we do not know.  We do not know
whether this stream_type will be one common value that is defined by various
MPEG-2 Standard Users (e.g. ATSC,ESTI,ARIB) or if it will be a private
stream_type with a MPEG-2 Registration Descriptor in some systems. A
world-wide single coordinated value will require some effort, but could
reduce complexity of implementations. 

Comment 4
Ref [ATSC-PSIP-TC] should read:
"[ATSC-PSIP-TC] A/65B Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television Systems Committee
(ATSC), Doc. A/65B, 18 March 2003."

Comment 5
I noted that some references have dates, and some do not. Does the lack of a
date in an RFC mean that no matter what changes are made to that reference,
the new change immediately becomes effective and all deployed ULE devices
must comply or be in violation of the RFC? If this is the meaning of "no
date" ; it is a serious commitment. With a date it is clear that just the
specific version applies. I suggest dates should be on all normative
references.

Comment 6
WRT to the TS logical channel issue, while I agree with Mr. Goldberg about
what would have been a better approach; the decision was taken by the group
and the term was created for better or worse. So as we are married to it,
the only issue is definition of the new term being accurate and sufficient,
and I find that this draft is acceptable in that regard.

Comment 7
As you asked for affirmations, the remaining changes are <acceptable> to me.

____________
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] 
Sent: Friday, February 11, 2005 6:58 AM
To: ipdvb@erg.abdn.ac.uk
Cc: Goldberg, Adam; Allison, Art; Matthew Goldman
Subject: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE


I'm going to allow a few days for a "final signoff" of the ULE spec, until
15th Feb 2005 (one week from the email below).

Specifically, I'm looking for the folks who made comments during last call
to check the doc and either indicate "looks OK" or if necessary, submit
replacement text. At this stage, it is important to get "positive" responses
(as well as raising any issues), so if you have  looked at the changes and
agree with them, please do send a brief email to the list saying so.

Once submitted, there will be only one last chance to correct this, during
the final IETF Last Call period, after which this document will be
published.

The document is at:
http://www.erg.abdn.ac.uk/ip-dvb/ids/draft-ietf-ipdvb-ule-05f.txt

The complete set of proposed changes are listed at:
http://www.erg.abdn.ac.uk/ip-dvb/ids/rfcdiff-ule-05f-04.html


-- Gorry.

<snip>