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

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Thanks, Art, your comments have much improved this document,

Gorry


Allison, Art wrote:

> 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]."

We take your text, no problem with that.

>
> 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.

draft-ipdvb-ar-xx *should* also talk about a number of scenarios including 
common uses of MPE (but this will require more inputs and text - Marie Jose, 
I'm sure would appreciate inputs to this).

> B) <also> The word 'also' was inserted as draft-ipdvb-ar will supplement not
> replace the ISO standards.
>
Absolutely appropriate to this document.

> 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.

No text change - Byte-order should not be an issue, since all RFCs should 
order bytes in the same way.

> 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.

OK, then we use your text.

> 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."

Done, thanks.

> 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.

I don't think the IETF has a single convention on this, but I'd agree with 
your statement. The problem is that since RFCs are not updated, the normative 
references are simply those that were normative when the document was written.

So, I have changed this to:

   [ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic
   coding of moving pictures and associated audio information -- Part
   1: Systems", International Standards Organisation (ISO), 2000.

> 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.
>

OK - and we do need to bear the usage of this term in mind when this WG 
produces other documents.

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

OK, Thanks.

> ____________
> 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>
>
>