RE: Question regarding SessionType

Agreed, the SHOULD is now added to section 5.

Thanks.

Mallikarjun


--- [email protected] wrote:

> I think a "SHOULD" in the Implementer's Guide for
> the suggestion Ken
> makes is fine:
>  
>     if the SessionType key is going to be set to
> "Discovery", it SHOULD
>     be set in the initial Login request
>  
> Declaring one's intentions up front seems like a
> good idea in general.
>  
> Thanks,
> --David
> ----------------------------------------------------
> 
> David L. Black, Senior Technologist 
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> 
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> 
> [email protected]        Mobile: +1 (978) 394-7754
> 
> ----------------------------------------------------
> 
> 
> 
>   _____  
> 
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Julian
> Satran
> Sent: Monday, December 05, 2005 7:08 AM
> To: Ken Sandars
> Cc: [email protected]; Sears, Bill
> Subject: RE: [Ips] Question regarding SessionType
> 
> 
> 
> Ken, 
> 
> Even if we put is a good practice in the
> implementer's guide it would merely
> help in avoiding some nasty bugs in the initiator
> and/or target. And we
> can't mandate it in the implementoer's guide. 
> 
> The supporting code for all the exceptions you
> mention has to be there and
> not only because of the session type placement but
> because the normal
> session type has to be supported. All of your
> arguments would make sense
> only if you envision an implementation that supports
> the two session types
> with separate pieces of code or even boxes. 
> 
> Julo 
> 
> 
> 
> "Ken Sandars" <[email protected]> 
> Sent by: [email protected] 
> 
> 
> 05-12-05 08:15 
> 
> 
> To
> "'Julian Satran'" <[email protected]>,
> <[email protected]> 
> 
> cc
> [email protected] 
> 
> Subject
> RE: [Ips] Question regarding SessionType
> 
> 	
> 
> 
> 
> 
> Hi Julo,
> 
> I think there is merit in having a recommendation in
> the implementor guide
> that if the SessionType key is going to be set to
> "Discovery", it should be
> set in the initial Login request.
> 
> Clearly this only affects named sessions since the
> only legal unnamed
> session requires SessionType=Discovery in the
> initial Login request.
> 
> Say an initiator wants to create a named discovery
> session but doesn't
> supply SessionType in the initial Login request. The
> target will assume the
> SessionType is Normal (as it is the default value),
> and negotiate
> accordingly. Some consequences of this are:
> 
> 1. The initiator will have to be prepared to
> negotiate Normal session
> parameters which the target may offer - such as
> MaxConnections,
> MaxBurstLength, etc.
> 
> 2. If a target is configured to operate without
> security for Discovery
> sessions but with it for Normal sessions, the
> initiator cannot successfully
> bypass the security phase.
> 
> 3. The target might make different resource
> allocation decisions dependant
> on the type of session. A Discovery session has much
> less scope for
> consuming system resources than a Normal session.
> The target implementation
> may reject the login due to resource constraints
> when in fact there are none
> for this session.
> 
> 4. Some keys must be negotiated with knowledge of
> the SessionType. For
> example, in the implementor's guide, section 5.1 -
> the ErrorRecoveryLevel
> value MUST be negotiated to 0 for Discovery
> sessions.
> MaxRecvDataSegmentLength might be declared
> differently for different session
> types so the target has to hold off with its
> declaration until either the
> final Login request or SessionType is explicitly
> declared.
> 
> While none of these consequences are show-stoppers,
> they do add complexity
> which would be nice to avoid. To recommend this in
> the implementor guide
> should have very little impact as I don't think the
> named-discovery session
> is in common use (at all?).
> 
> 
> Thanks,
> Ken Sandars
> 
> > -----Original Message-----
> > From: [email protected]
> [mailto:[email protected]] On 
> > Behalf Of Julian Satran
> > Sent: 30 November 2005 01:53
> > To: [email protected]
> > Cc: [email protected]
> > Subject: Re: [Ips] Question regarding SessionType
> > 
> > 
> > Bill,
> > 
> > Unfortunately the text of RFC3720 does not agree
> with your 
> > assumptions.
> > The session type can be specified at any stage as
> explicitly 
> > stated in 
> > chapters 11 and 12.
> > I can't think of a good reason we should limit its
> use (or even 
> > recommend it as good practice in the implementor
> guide).
> > 
> > Julo
> > 
> > [email protected] wrote:
> > >
> > >  
> > >
> > > rfc3720 section 5.3 states:
> > >
> > > The initial login request of the first
> connection of a session MAY 
> > > also include the SessionType key=value pair.
> > >
> > > The use of the word 'MAY' here is bothersome.  
> Does this 
> > mean that an 
> > > initiator may leave out the session type in the
> first 
> > request but then 
> > > explicitly specify it later?  This seems
> possible but very 
> > annoying.  
> > > For example:
> > >
> > > During Security stage it seems that an initiator
> could leave out 
> > > SessionType but specify a
> TargetName=<something>.   Later during 
> 
=== message truncated ===>
_______________________________________________
> Ips mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips
> 



		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 


_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips