ULE Extension Headers

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

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.)
So maybe we have acceptance of an approach for this item?

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: Monday, March 08, 2004 10:51 AM
To: ip-dvb@erg.abdn.ac.uk
Subject: ULE : Encryption Support, FEC, and Extension headers.



There's been a lot of discussion on the list about three related topics:
    (i) The (potential/actual) need for FEC and Encryption
    (ii) How to implement headers in ULE to support Encryption
    (iii) Whether ULE should support optional extension headers.

I don't wnat to stop any of this debate, but I would like to try and put
a marker in the email threads so that those not following the detail
of the various discussions, have a picture of where the group seems
to have consensus.
   
So here's my recommendation as WG Chair:

(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 optionaly 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).

(2) FEC and Encryption, the requirements for these must be clearly
defined in an Internet Draft (reference could be made to other, e.g.
ETSI documents). This could be one or more individual drafts -
or by contribution of IETF-style text for the "ipdvb requirements" ID. 
This will assure, we have a common basis for discussion, either on the
mailing list or (if issues do prove hard to resolve in this way) at the
San Diego IETF. I'm anxious ULE collects only *useful* options.
Note: These individual ID's could be very short (a few pages) and
could finally be "combined" into the ULE (and/or requirements) text,
should they be accepted by the group.

(3) After production of a WG ULE ID, I'd like the WG to progress the
charter item of adopting a requirements WG Internet Draft. This document
must provide background, identify use-cases, and implementation options;
leading to appropriate recommendations.  We can either start from the
existing (somewhat imperfect/incomplete) requirements draft:

http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt

....or make one (or more) new ones. Thoughts?

Gorry Fairhurst
(ipdvb WG Chair)