Subject: RE: ULE encryption Support.

From: "Allison, Art" <[email-masked]>
Date: Mon, 1 Mar 2004 10:44:05 -0500

So, if we should not encrypt at this layer [agree with Alain] and we should
not put additional error correction at this layer.. it seems we no longer
have a reason to add more than a just-in-case escape bit just in case a
yet-to-be-invented function is needed someday.  

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

-----Original Message-----
From: Alain RITOUX [mailto:[email-masked]]
Sent: Monday, March 01, 2004 10:40 AM
To: Allison, Art
Cc: [email-masked]'
Subject: Re: ULE encryption Support.

Allison, Art wrote:

> Thanks for the post about layering, Gorry.. it does seem that we don't
stick
> to the 'right' place in the stack in all out posts. 
> As far as the place in the layers for duplication of transport packets,
that
> seems to me to be at the MPEG-2 transport layer, not above it.   I read
> Gorry pointing to the first phrase of #2 when he says this group is
focused
> on #2 as the rest is explanation of the underlying protocol.

I defintively agree.

All proposition that I made, where about the possibility of Extension
Headers, and its mechanisms.

The reference about encryption and/or FEC was for me JUST an example of
usage. It DOES NOT imply support for the FEC / encrpyt  / whatever
function at this level. I should have kept the 2 subjects more
separated. In fact :
  - for FEC, I have no expertise on that subject, and have no opinion.
  - for Encrypt, I believe it is not in the correct layer to do this.

Regards.
Alain.

-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com

---

From: Alain RITOUX <[email-masked]>
Date: Mon, 01 Mar 2004 18:08:14 +0100

> yet-to-be-invented function is needed someday.  

Not totally agree. This "reserve" may have no usage now, but the
mechanism is not that heavy, and once it is done, it will allow
introduciton of "possible" ext headers in a backward-compatible
way, which seems to me worth the price.

Cheers
Alain.

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 08 Mar 2004 15:51:09 +0000

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)