RE: ULE encryption Support.

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

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:alain.ritoux@6wind.com]
Sent: Monday, March 01, 2004 10:40 AM
To: Allison, Art
Cc: 'ip-dvb@erg.abdn.ac.uk'
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