Subject: Re: [Ips] Question regarding SessionType

From: Julian Satran <[email-masked]>
Date: Tue, 29 Nov 2005 16:52:40 +0200

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-masked] 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 
> operational stage the initiator could specify SessionType=Discovery.  
> It seems that this is allowed.
>
> Currently I am assuming that if the SessionType is not specified in 
> the initial login request of the first connection that the initiator 
> is implicitly negotiating for SessionType=Normal.   In this case I 
> wont send SessionType=Normal in a response PDU but I will assume that 
> SessionType has been negotiated to its default value of Normal.   I 
> regard seeing SessionType in any subsequent LoginRequest PDU as an 
> error. 
>
>  
>
> Bill
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
>   

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

---

From: "Ken Sandars" <[email-masked]>
Date: Mon, 5 Dec 2005 17:15:54 +1100

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-masked] [mailto:[email-masked]] On 
> Behalf Of Julian Satran
> Sent: 30 November 2005 01:53
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ips] Question regarding SessionType
> 
> 
> Bill,
>

---

From: Julian Satran <[email-masked]>
Date: Mon, 5 Dec 2005 14:08:11 +0200

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-masked]> 
Sent by: [email-masked]
05-12-05 08:15

To
"'Julian Satran'" <[email-masked]>, <[email-masked]>
cc
[email-masked]
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.

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:

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.

MaxRecvDataSegmentLength might be declared differently for different 
session

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

---

From: William Studenmund <[email-masked]>
Date: Mon, 5 Dec 2005 21:09:41 -0800

> accordingly. Some consequences of this are:

Ken, a solution to this issue is that it is legitimate for the target 
to reject SessionType=Discovery. Thus if you get a 
SessionType=Discovery after the initial PDU, just reject it. Section 
12.21 states this explicitly.

Take care,

Bill

---

From: "Ken Sandars" <[email-masked]>
Date: Tue, 6 Dec 2005 23:57:11 +1100

Hi Bill,

Thanks for pointing that out - a handy escape hatch!

Cheers
Ken

> From: William Studenmund [mailto:[email-masked]] 
> Sent: 06 December 2005 16:10
> To: Ken Sandars
> Cc: 'Julian Satran'; [email-masked]; [email-masked]
> > I think there is merit in having a recommendation in the 
> implementor 
> > guide