RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

["Gary Kenward" <[e-mail]>]

The point was not that the parameters will be the same or different.
The point was that discussion of the context make up is out of scope
for Seamoby, and discussion of QoS parameters is out of scope for
NSIS. It is too great a leap of faith to say that the NSIS parameters
will be the configuration context. Thus, while I agree that the two
protocols must interwork, there is nothing we can do about matching
the NSIS parameters with the Context, without a change in charter.

The one step we could take (but not the one that was suggested) would 
be to investigate into ensuring some commonality between the formats for
encapsulating the respective data chunks (i.e. context/NSIS parameters). 
Or at least, provide for NSIS to carry CT data chunks and visa versa.

gary

> -----Original Message-----
> From: James Kempf [mailto:[e-mail]]
> Sent: July 11, 2002 12:28
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Geib, Ruediger';
> [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00. txt
> 
> 
> > CT is not a service establishment protocol; it tranports
>        forwarding context, not service description parameters. Some
>        of the forwarding context *may* be the original 
> service description
>        parameters, but many *may* be derived values that allow a more
>        representative description of the AR forwarding context.
> 
> If the service description parameters are involved in 
> fowarding, then the two are the same, right? Will there be any
> difference for QoS?
> 
> 
> > For the two groups should discuss the common parameters would be a
>        violation of the respective charters. I think that this is an
> excellent
>        idea, but I believe it will have to take place outside of the
> NSIS/Seamoby
>        wgs, and I suggest that it would be best if we knew 
> what the CT/NSIS
>        protocols were - at the very least, we can proceed with the
> definition
>        of the protocols.
> 
> We have to make sure the two protocols work well together.
> 
> CT is not specific to QoS, so I don't see any overlap, but 
> when it comes time to define the QoS feature context type, perhaps
> that definition can be done by the NSIS group, or in 
> conjunction with it in some way. Requirements, for example.
> 
>             jak
> 
>