RE: Further comments on the proposed RFC

["Walsh Rod (NRC/Tampere)" <Rod.Walsh@nokia.com>]

Hi Gorry et al.

Thanks for the super fast response. Just a few answers with text cut...

> GF: Yes, do we need a different one for the return path too?

I do not feel the need to include them, but am happy to see them from
anyone keen on DVB radio return channels. (Just that the two paths
should be illustrated seperately to keep understanding clear).

> GF: I'll just call them sections if it is clearer.
> So.... in the rev I am writing, I now have:
> |         | | | | |   | AAL5 | DSMCC  |  |  |
> |         +-+-+-+-+---+------+--------+--+--+
> |         | PES  |   ATM     |  Sections    |
> +---------+-------+----------+--------------+

"Private Sections" is the correct term. "DSM-CC Sections" may also be
called "sections" - "Priv.Sect." fits the space:)

> GF: I agree, I suggest at the moment to talk only about "SI" 
> in the most general sense.
...
> Is that OK, or would you like to suggest alternate?

That's great. Alternatives aren't needed in the current document scope.

> GF: In the version I am working on (I'll send this out in the next
> week, so everyone can look at it), a "TS Multiplex" is a 
> series of consecutive transport packets all sent over the same
physical
> link. This is a key term - we need to get the right name and meaning.
...
> Would that be OK?
> Would "TS logical channel" be better, "TS Channel" is shorter?
...
> GF: I'll write new text and see if we can converge.

"TS logical channel" is better, but even so we'll have some terminology
issues. "Component" seems to fit best, but I'm open to better arguments.
Also check the IP-CC requirements pdf previously posted to the reflector
- there are some definitions originating from DVB which should be
useful.

> GF: Nice idea!!! I'm not sure this IETF work, maybe it is?
> - It would be useful to have an ID on this, so we could
> evaluate how easy it would be to define benchmarking
> terms and appropriate tests. 

"RFC2357 IETF Criteria for Evaluating Reliable Multicast Transport and
Application Protocols" or "RFC2477 Criteria for Evaluating Roaming
Protocols" may be good a example of how this could be done in the IETF
context.

> GF: Do we need bi-directional (duplex) communication between end hosts
to
> use IPSEC - I thought providing you could distribute keys, one-way
would
> be fine --- can someone check this?

It is not essential to use a bi-directional link for IPsec key delivery.
But if we include IPsec issues we must not exclude a return channel
(since it will "probably" offer higher security).

Yours,
Rod Walsh.