Re: ULE Extension Headers

["Marie-Jose Montpetit" <mariejose.montpetit@verizon.net>]

I disagree with the "if needed" and would like to see the extension headers
as part of the new revision even if the actual mechanism is TBD. We can come
up with a series of concrete use cases. I think extension headers are
essential to support future services (security being one) and ensure
extensibility.

Marie-Jose
----- Original Message ----- 
From: "Allison, Art" <AAllison@nab.org>
To: <ip-dvb@erg.abdn.ac.uk>
Sent: Wednesday, March 10, 2004 11:34 AM
Subject: ULE Extension Headers


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