RE: ULE Extension Headers

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

William
I do not see how referring me to old posts without taking a position
facilitates progress. I was not and am not attempting to reopen discussion.
It seemed that it was time for preferences to be expressed. Given the
clarifications and lack of continued objection; it seemed to me that maybe
(b) had enough support. So calling for a measurement of consensus seemed in
order.

The alternatives that were clearly set forth by our esteemed Chair and are:

 'a', 'b', 'c' or 'no choice'.

So if each of us that cares asserts "I prefer (x)" or "for the reasons I
have previously posted I  prefer (y)" we provide data upon which a way
forward can be based. It is most reasonable to interpret silence is "I don't
care". 

I stated my preference. I urge helping the Chair to avoid having to report
'no choice' by stating yours.

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


-----Original Message-----
From: William StanisLaus [mailto:williams77@rediffmail.com]
Sent: Wednesday, March 10, 2004 12:21 PM
To: ip-dvb@erg.abdn.ac.uk
Subject: Re: ULE Extension Headers


Hi Art,
  Please refer the previous post on definition to the proposal (b) which
describes the ext. bit.

http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00584.html

Best Regards,
William.

On Wed, 10 Mar 2004 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.)
>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)
>