RE: ULE Extension Headers

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

With respect, I have seen no one register any other preference than (b) on
list. I have been doing standards work for over 20 years and one always
wants to get all folks to express their position, but if they will not then
those who do represent the consensus and you move on.

I don't see lack of a consensus in this matter, by any standard for
consensus.  Perhaps there is off-list correspondence, but with respect that
is not appropriate to consider here.

Gorry, if you do not support (b), and are feel your posting is inhibited
because you are the Chair, perhaps just post with your "Chair hat off" for
the record.

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
Sent: Thursday, March 11, 2004 11:28 AM
To: ip-dvb@erg.abdn.ac.uk
Subject: Re: ULE Extension Headers



Let's see if I can help steer this discussion.

* I note there is some enthusiasm to consider the idea of a ULE extension
header. That is useful to know, but I don't see a consensus YET.

* As I said earlier, I am against holding-up the publishing of the first rev
of the ULE WG draft.  I believe we should publish the draft as soon as
possible (next week), to make sure the rest of the text is acceptable to the
WG. We CAN issue a new revision of the ID soon after with this new
functionality (if we are ready) - there's no minimum time between
revisions!!!

Here is my suggestion to progress the extension header topic:

* We need first to at least find a list of examples of likely/potential
use...  Let us do this in the context of setting some (potential/actual)
requirements/architecture - this also is a WG charter item!  Any volunteers
of 1-3 paragraphs of ID text describing for each of the ideas for use:
Security; FEC; QoS; priority; Multiple-SNDU-Payload; anything else?

* I'm not yet clear of the relative costs of (a,b,c) in terms of
implementation, registry management, transmission efficiency - one thing
that would be very useful would be to write a short ID with a proposed
solution, to have something concrete to compare the design options with.

Any volunteers for either of the above?

Gorry

P.S. I didn't mean to ask for a vote (a,b,c) - I was trying to summarise the
options I had seen... Sorry if that caused some confusion.

On 10/3/04 5:32 pm, "Alain RITOUX" <alain.ritoux@6wind.com> wrote:

> 
> 
> Allison, Art wrote:
>> Taking one....
>> (1) ULE Extension Headers - We have described a number of ways we can
>> encode extra headers associated with a specific SNDU, that a receiver
>> may optionally ignore without having to discard a PDU. However, we
>> have yet to agree if this is needed and which way is best. The most
>> promising seem to be:
>>     (a) use a 16-bit type field to indicate "extension header follows"
>>     (b) use a 1-bit flag to indicate "extension header follows"
>>     (c) the assignment of type field values to identify each
>>         individual extension header.
>> 
>> I recommend we add only a "place holder note" in the next revision of
>> the ULE draft (to be released in about one-two weeks) which says the WG
>> could possibly consider future extension headers (if needed), and
>> continue this discussion for the next revision (this can happen quickly
>> if the WG gets consensus, at the moment I see too many options
>> and unclear concrete examples).
>> 
>> ----
>> I thought discussion faded to silence after I <effectively> acknowledged
(b)
>> was ok with me. (And I thought some wanted to define the following
structure
>> when the bit is set - an activity to which I do not think there were
>> objections.)
> 
> I also am in favour of b) A structure was proposed for the case where
> the bit is set. I didn't feel any strong objection against the proposed
> definition, neither a great support ;-) but we were just 3 or 4 to
> discuss about it, I don't know the feeling of the WG about this stuff.
> How to proceed any further ?
> 
>> So maybe we have acceptance of an approach for this item?
> maybe.
> 
> Cheers.
> Alain.