[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ULE Extension Headers
To my opinion extension headers management is definitely needed. For this I
am in favour of 'b' solution.
Benoit Oger
Thales Broadcast and Multimedia
> -----Message d'origine-----
> De : owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]De
> la part de Allison, Art
> Envoyé : mercredi 10 mars 2004 19:26
> À : 'ip-dvb@erg.abdn.ac.uk'
> Objet : RE: ULE Extension Headers
>
>
> 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)
> >