RE: [NSIS] Plans for the protocol drafts

hi cheng, 

you find a small comment inline:

> -----Original Message-----
> From: Cheng Hong [mailto:hcheng@psl.com.sg]
> Sent: Friday, March 26, 2004 3:02 AM
> To: sven.van_den_bosch@alcatel.be
> Cc: john.loughney@nokia.com; nsis@ietf.org; 'Georgios Karagiannis';
> 'McDonald, Andrew'; 'Allison Mankin'
> Subject: RE: [NSIS] Plans for the protocol drafts
> 
> 
> Hi Sven,
> 
> Thanks for your reply. Please see some further comments below:
> 
> <Snip>
> > 
> > This may not be opaque to QoS NSLP.With this RESERVE/COMMIT 
> > model, QoS NSLP should include messages that could do the 
> > roll-back action.
> > 
> > Sven>> Can you clarify what the impact on QoS NSLP would be? I would
> > imagine the signalling to look exactly the same from QoS NSLP 
> > perspective with an additional indication to commit 
> > resources. It seems that this difference mainly makes sense 
> > for the Resource Management Function (RMF), which does not 
> > participate in QoS NSLP processing anyway.
> 
> I think this depends on whether we want to make the QoS NSLP support
> RESERVE/COMMIT or letting individual QoS Model to support 
> that. If the QoS
> NSLP needs to support it, some information element, e.g. a flag and
> corresponding RSN, should be included in the common header of QoS NSLP
> messages. 
> 
> If the QoS Model is left to deal with it, the above 
> information could be
> placed into QSPEC. Then, the QSPEC should contain an object 
> defined for this
> purpose. 
> 
> 
> 
> <snip>
> > The resource sharing is only meaningful inside each 
> > individual NSLP. Therefore, the GIMPS may not be able to 
> > provide the necessary function unless it is mandated that the 
> > session-ID would be unique across all the NSLPs.
> > 
> > Sven>> Since the session ID is a large random identifier, why 
> > would it 
> > Sven>> be
> > "less unique" across NSLPs than within one NSLP?
> 
> Statistically, it would not be very much "less unique". But since this
> feature we want to introduce here depends on the uniqueness 
> of the ID, it
> should be made explicit. Maybe some guideline should be given 
> in framework
> stating that different NSLP should use different session-ID. 
> Otherwise, in
> implementation, a node could conveniently reuse the same 
> session-ID for
> different NSLP applications since nothing forbids that. 

i tried to address issues of the session id construction for a long time.
unfortunately, i haven't received too many comments yet. 
a discussion of the importance of a security property called sender
invariance can be found in the current mobility id and also in separate
draft: 
http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-sid-00.txt

your comments are highly appreciated. 

ciao
hannes

> 
> 
> <snip>
> > This could be useful if we want to differentiate the flows, 
> > and assign different priority for different flows. In that 
> > case, reservation for the corresponding flows could also be 
> > assigned with priority.
> > 
> > Sven>> OK. Do you see it as part of the QoS NSLP or as part 
> of the QoS
> > model (opaque to QoS NSLP, handled by RMF)?
> 
> It depends on how the priority would be used. Does it have 
> meaning across
> the QoS Models? Will there be multiple QoS Model at each node 
> shareing the
> same RMF? My feeling is that make it part of QoS NSLP may be 
> better or it
> could be a mandated part of QSPEC. 
> 
> 
> 
> <snip>
> > Does this imply that at least one end of the flow would be 
> > the QoS NSLP node?
> > 
> > Sven>> Do you want to support bi-directional reservation for 
> > cases where
> > the first QoS NSLP node on the path is different for the 
> > forward and reverse direction? Bi-directional reservation is 
> > mainly an optimization. Wouldn't you rather leave these 
> > "strange" cases unoptimized?
> 
> Agree. This doesn't have to be the focus at this stage. But 
> should we state
> clearly that this case is for future development?
> 
> best regards
> 
> Cheng Hong
> 
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis