RE: Proposed Changes to ULE text - Format descriptors for SI sign alling

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

Ahh, point taken. In the encapsulation work, SHOULD seems appropriate
and matches the scope.  In the transport/binding/association using a
MPEG-2 delivery system, a SHALL of some form seems correct. I apologize
for missing the context as I thought we were discussing the transport
work , not the final encapsulation work, as the time for substantive
change discussion about that is past. Unless someone proved it is
broken.)

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

-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] 
Sent: Tuesday, August 02, 2005 9:53 AM
To: ipdvb@erg.abdn.ac.uk
Subject: Re: Proposed Changes to ULE text - Format descriptors for SI
sign alling


Art, others, I'd like to respond to the SHOULD/SHALL thread as the WG
Chair.

The reason an additional paragraph was inserted, was to associate a ULE
stream with a format descriptor that had been allocated by SMPTE. This
now forms one of three paragraphs in the introduction of the ULE
encapsulation spec. Looking at the thread, I believe the term "SHOULD"
in the new para is correct in the IETF sense, in that there are cases
where the ULE protocol could function without the information (e.g. A
private network). This was also discussed on the list earlier.

I'll present a slide with this text again at the IETF meeting tomorrow,
and if there are more views, I'll make sure they are discussed on this
list.

Although the *encapsulation* work is now complete, the topics of
addressing and identification of the set of TS to be used is now very
much a work-in-progress. 

The AR document (see below) is intended to describe the process of
binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams
(TS).
In this latter context, the discussion seems valuable. The AR document
needs to explain why and how to use the PMT, when you need it, when you
may not do it, and what other protocol parameters need to be set to
complete the mappings for IPv4/v6 multicast/unicast etc. This discussion
thread provides useful inputs to this document, which we will try to now
include in section 4.
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-00.txt

Gorry