William Studenmund | 1 Dec 18:03 2005

Re: Fast multi-task abort model

On Nov 29, 2005, at 5:34 PM, Mallikarjun C. wrote:

> Hi Julian,
>
> Thanks for the review.
>
> I agree with you that CmdSN & StatSN ack wait on 3rd
> party sessions wasn't the original intent, and both
> should be errata noted in the implementer's guide.
>
> The third major source of delay comes from the TTT
> wait - it's a cross-nexus delay and RFC 3720 requires
> it for completing the original TMF.  The Async-NopIn
> exchange enables us to take this wait out of the
> "performance path" by giving the target iSCSI layer a
> definitive event to free up the TTTs in a lazy
> fashion.

Why does it need to be cross-nexus, other than the fact that RFC 3720 
says it should be?

My thought is that we just revise it to not be cross-nexus. Yes, a 
given session is in the "waiting for things to stop" state until the 
TTTs clear, but as long as the "instant of death" I mentioned in my 
other mail has happened, I don't think that the TMF needs to wait.

> I don't like mandating TAS=1 for several reasons - a)
> it's a SCSI feature, b) it's not a default control
> mode page setting, c) it makes it harder to build
> iSCSI-to-XYZ bridges, d) puts iSCSI in a minor
(Continue reading)

Black_David | 1 Dec 19:20 2005

IPS WG - MIB status

The IESG has just approved the FCIP MIB as an RFC; the
announcement of this will appear shortly, after which it'll
land in the RFC Editor's Queue, so this seems like a good
time to update the WG on the status of our other MIBs.

The iFCP MIB was approved by the IESG in October and is
already in the RFC Editor's Queue.

The SCSI MIB requires a revision to address issues found in
expert review by the assigned MIB Doctor.  That revised draft
is expected in the next couple of weeks.

The iSCSI MIB is in good shape - the expert review comments
found by the assigned MIB Doctor have been addressed in the
current version, but we're holding it up so that it will go
to IETF Last Call together with the Authorization MIB.

The Authorization MIB will need to be revised, but we don't
have all the comments needed to generate the revision, yet.
The end of year holidays are going to get in the way, but
I hope to see this get through MIB Doctor expert review by
mid-January after which a revised version will be needed.

The iSNS MIB is still in the working group.  Major changes
(including significant reduction in scope) are going to be
performed, and unfortunately, the authors have encountered
delays in getting the changes done.  The current ETA for the
revised draft of this MIB with the structural change is the
end of January, so it's going to miss the current December
2005 goal for submission to the IESG - given the continuing
(Continue reading)

Mallikarjun C. | 2 Dec 01:01 2005
Picon

Re: Fast multi-task abort model

> Why does it need to be cross-nexus, other than the
> fact that RFC 3720 
> says it should be?

There's a good rationale behind RFC 3720 text:

TMF cannot complete until all affected tasks are
terminated on the target per SAM.  Receiving stale
data after tasks are terminated is a problem.  Waiting
for all active TTTs of all affected tasks (same and/or
other nexus) to finish was thus the adopted approach
to avoid stale data for any affected task.

What the new proposal does is to make receiving stale
data after task terminations a non-problem - via a
separate accounting scheme and new target semantics.

Mallikarjun

--- William Studenmund <wrstuden <at> wasabisystems.com>
wrote:

> On Nov 29, 2005, at 5:34 PM, Mallikarjun C. wrote:
> 
> > Hi Julian,
> >
> > Thanks for the review.
> >
> > I agree with you that CmdSN & StatSN ack wait on
> 3rd
(Continue reading)

Julian Satran | 2 Dec 20:17 2005
Picon

Re: Fast multi-task abort model


Regrdless of the TMF completion - discarding old TTT tagged data buffers is problems third party target sessions will face unless they know for sure that none can be expected in a safe way.

Julo


William Studenmund <wrstuden <at> wasabisystems.com>
Sent by: ips-bounces <at> ietf.org

01-12-05 19:03

To
"Mallikarjun C." <cb_mallikarjun <at> yahoo.com>
cc
IPS <ips <at> ietf.org>
Subject
Re: [Ips] Fast multi-task abort model





On Nov 29, 2005, at 5:34 PM, Mallikarjun C. wrote:

> Hi Julian,
>
> Thanks for the review.
>
> I agree with you that CmdSN & StatSN ack wait on 3rd
> party sessions wasn't the original intent, and both
> should be errata noted in the implementer's guide.
>
> The third major source of delay comes from the TTT
> wait - it's a cross-nexus delay and RFC 3720 requires
> it for completing the original TMF.  The Async-NopIn
> exchange enables us to take this wait out of the
> "performance path" by giving the target iSCSI layer a
> definitive event to free up the TTTs in a lazy
> fashion.

Why does it need to be cross-nexus, other than the fact that RFC 3720
says it should be?

My thought is that we just revise it to not be cross-nexus. Yes, a
given session is in the "waiting for things to stop" state until the
TTTs clear, but as long as the "instant of death" I mentioned in my
other mail has happened, I don't think that the TMF needs to wait.

> I don't like mandating TAS=1 for several reasons - a)
> it's a SCSI feature, b) it's not a default control
> mode page setting, c) it makes it harder to build
> iSCSI-to-XYZ bridges, d) puts iSCSI in a minor
> competitive disadvantage wrt other transports, e) it
> does not address the TTT problem with a
> multi-connection issuing session.  So I am glad you
> like the Async PDU approach.

I agree with (c) and (e), and they are enough to make me not like the
TAS=1-required idea.

> I would let David comment on the RFC revision part -
> but given all the other things we have been collecting
> in the iSCSI implementer's guide and given the guide
> will be published as an RFC that "updates" RFC 3720, I
> think it should be OK to include the new behavior in
> the guide.

Just to be clear, I like both the new abort proposal (AsyncEvent 5) and
also removing all long-wait inter-nexus delays. Obviously the
abort/reset will have to have started on all nodes before the TMF is
returned. :-)

Take care,

Bill
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

Attachment (PGP.sig): application/octet-stream, 264 bytes
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Black_David | 3 Dec 19:54 2005

RE: iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement

Independent of "legal best", "practical best" is the Implementers
Guide where we can say things like "not REQUIRED" to make it
abundantly clear.
 
RFC Errata processing is currently broken for all practical purposes
at the RFC Editor.
 
Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------


From: ips-bounces <at> ietf.org [mailto:ips-bounces <at> ietf.org] On Behalf Of Julian Satran
Sent: Saturday, November 19, 2005 7:59 PM
To: William Studenmund
Cc: ips <at> ietf.org; Pittman, Joseph; ips-bounces <at> ietf.org
Subject: Re: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement


You are right and we have to fix this somewhere (errata is probably the legal best). Julo


William Studenmund <wrstuden <at> wasabisystems.com>
Sent by: ips-bounces <at> ietf.org

15-11-05 13:28

To
Julian Satran/Haifa/IBM <at> IBMIL
cc
ips <at> ietf.org, "Pittman, Joseph" <Joseph.Pittman <at> netapp.com>
Subject
Re: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement





On Nov 15, 2005, at 1:29 AM, Julian Satran wrote:

> William Studenmund <wrstuden <at> wasabisystems.com> wrote on 14-11-2005
> 21:26:31:
>
>  > Waiting for other sessions to finish any form of processing is my
>  > biggest concern with how we handle aborts.
>
> Joseph concern (as I read it) was related to waiting for status ack on
> other nexi before handing the initiator the response to the TM
> command.
> This is not required by iSCSI.

Actually, I was just re-reading the Abort Task Set and Clear Task Set
text, and the status ack requirement is in RFC 3720. It's in section
10.6.2 on page 136, in step d) of the "The target:" events section:

         d) Takes note of last-sent StatSN on each of the connections in
            the iSCSI sessions (one or more) sharing the affected task
            set, and waits for acknowledgement of each StatSN (may
            solicit for acknowledgement by way of a NOP-In).  If some
            tasks originate from non-iSCSI I_T_L nexi then the means by
            which the target insures that all affected tasks have
            returned their status to the initiator are defined by the
            specific protocol.

So the concern Joseph has (which I also have as best I understand
everyone's position) does apply to RFC 3720. :-|

Take care,

Bill
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Black_David | 3 Dec 20:06 2005

RE: Fast multi-task abort model

> > I would let David comment on the RFC revision part -
> > but given all the other things we have been collecting
> > in the iSCSI implementer's guide and given the guide
> > will be published as an RFC that "updates" RFC 3720, I
> > think it should be OK to include the new behavior in
> > the guide.
> 
> Just to be clear, I like both the new abort proposal (AsyncEvent 5) and 
> also removing all long-wait inter-nexus delays. Obviously the 
> abort/reset will have to have started on all nodes before the TMF is 
> returned. :-)

Yes, as long as this is fully backwards compatible (which will
be achieved via negotiation of the next text key on login), it's
fine to include in the implementer's guide.

Taking off my WG Chair hat, I think the new abort proposal (AsyncEvent 5)
is a good idea, but I'm going to be looking to Mallikarjun, Bill, Julian,
and others on the list to work through all the details.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

Black_David | 3 Dec 20:20 2005

IPS WG will meet in March in Dallas

Unless I hear strong objections to the contrary, I will
schedule a meeting of the IP Storage (ips) WG at the next
(65th) IETF meeting in Dallas in March.  I'm announcing this
now since the IPS WG did not meet in Vancouver last month.

There are two primary reasons for meeting in Dallas:
- Progress check on the iSCSI Implementers Guide draft.
	In particular, some face-to-face time with diagrams
	could be quite useful in making sure that the details
	and corner cases are correct in the evolving multi-task
	abort proposal, as well as other task management cleanup.
- Review of the structural and functional changes in the new
	iSNS MIB.

In connection with the latter, this message serves to put the
iSNS MIB draft authors on notice that a revised draft of the
iSNS MIB that is deemed reasonably close to acceptable by the
WG Chair (me), the WG MIB Expert (Keith) and the responsible AD
(Allison) is required by the March IETF meeting, and the iSNS
MIB draft authors should plan for multiple versions of the MIB
between now and then to meet this goal.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

Ken Sandars | 5 Dec 07:15 2005

RE: 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: ips-bounces <at> ietf.org [mailto:ips-bounces <at> ietf.org] On 
> Behalf Of Julian Satran
> Sent: 30 November 2005 01:53
> To: Sears_Bill <at> emc.com
> Cc: ips <at> ietf.org
> 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
> 
> Sears_Bill <at> emc.com 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
> > Ips <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >   
> 
> 
> _______________________________________________
> Ips mailing list
> Ips <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

Julian Satran | 5 Dec 13:08 2005
Picon

RE: 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" <ken_sandars <at> adaptec.com>
Sent by: ips-bounces <at> ietf.org

05-12-05 08:15

To
"'Julian Satran'" <julian.satran <at> gmail.com>, <Sears_Bill <at> emc.com>
cc
ips <at> ietf.org
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: ips-bounces <at> ietf.org [mailto:ips-bounces <at> ietf.org] On
> Behalf Of Julian Satran
> Sent: 30 November 2005 01:53
> To: Sears_Bill <at> emc.com
> Cc: ips <at> ietf.org
> 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
>
> Sears_Bill <at> emc.com 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
> > Ips <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >  
>
>
> _______________________________________________
> Ips mailing list
> Ips <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>
>



_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Black_David | 5 Dec 16:28 2005

RE: Question regarding SessionType

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
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------


From: ips-bounces <at> ietf.org [mailto:ips-bounces <at> ietf.org] On Behalf Of Julian Satran
Sent: Monday, December 05, 2005 7:08 AM
To: Ken Sandars
Cc: ips <at> ietf.org; 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" <ken_sandars <at> adaptec.com>
Sent by: ips-bounces <at> ietf.org

05-12-05 08:15

To
"'Julian Satran'" <julian.satran <at> gmail.com>, <Sears_Bill <at> emc.com>
cc
ips <at> ietf.org
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: ips-bounces <at> ietf.org [mailto:ips-bounces <at> ietf.org] On
> Behalf Of Julian Satran
> Sent: 30 November 2005 01:53
> To: Sears_Bill <at> emc.com
> Cc: ips <at> ietf.org
> 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
>
> Sears_Bill <at> emc.com 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
> > Ips <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >  
>
>
> _______________________________________________
> Ips mailing list
> Ips <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>
>



_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

Gmane