Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

The architecture not only covers ULE, it covers methods such as MPE 
(DSM-CC encaps) and usage of the DVB INT Table, etc. It also includes 
the usage with UDLR, ARP, ND, etc as a networking technology.

So, if we're talking about arp, ND, then I was assuming this was all 
over a single PID (or potentially group of PIDs) and that this defined a 
subnetwork.

Gorry


Rod.Walsh@nokia.com wrote:
> We agree on this issue of scope. How about stating it explicitly in the document? (i.e. that address resolution for other TSes, e.g. for moving TS and mobility optimisation, is not in scope)?
>
> Cheers, Rod.
>
>
>
> > -----Original Message-----
> > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On
> > Behalf Of ext Gorry Fairhurst
> > Sent: Tuesday, November 02, 2004 1:17 PM
> > To: ipdvb@erg.abdn.ac.uk
> > Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt
> >
> >
> >
> > On clarification of the AR work scope:
> >
> > Rod.Walsh@nokia.com wrote:
> >
> > <snip>
> >
> > > * I get the impression that it is an intentional limitation 
> >
> > of the AR that it 
> > > applies only to the current TS (as you would expect cf 
> > ARP). This is 
> > a sensible
> > > limitation but it's worth stating explicitly.
> > > (i.e. that address resolution for other TSes, e.g. for 
> > moving TS and 
> > mobility
> > >  optimisation, is not in scope).
> >
> > <snip>
> >
> > > Cheers, Rod.
> >
> > My understanding was that the scope of any new work will be 
> > to resolve 
> > *within* a transport multiplex (i.e. a single physical bearer). The 
> > proposals to date do not allow the possibility of a TS 
> > logical channel 
> > (i.e. PID value) to be changed during (re)multiplexing - there are 
> > scenarios in which this can happen - and there are specific solutions 
> > already in this space (guidance on how to use these is within scope).
> >
> > Providing AR services that span multiple physical bearers is 
> > significantly more complex and typically requires processing 
> > of SI table 
> > information - solutions also already exist in this space e.g. 
> > proposed 
> > by ATSC and DVB (guidance on how to use these is within scope).
> >
> > I'd encourage an approach which is simple.
> >
> > Rod is that any help? Do other people have thoughts?
> >
> > Gorry