Subject: RE: description of recovery mechanisms

From: [email-masked]
Date: Thu, 8 Mar 2001 19:33:52 -0500

What Somesh is asking for is necessary.  We can
either put it in now, or discover it the hard
way later in interoperability testing with
considerably greater expenditure of time and
effort.

--David 

> -----Original Message-----
> From:	Somesh Gupta [SMTP:[email-masked]]
> Sent:	Wednesday, March 07, 2001 10:24 PM
> To:	[email-masked]
> Subject:	description of recovery mechanisms
> 
> I hope David and Julian will excuse me for using the following
> sentences from the Orlando minutes.
> 
> -----------  start of quote -------------------------------
> 
> - There will be a significant connection recovery write-up,
> 	including details, procedures and examples added to the draft.
> 
> -----------  end of quote ---------------------------------
> 
> 
> As an engineer, I believe that we do need detailed and thorough
> description of the usage of all the recovery tools in the
> protocol. This ensures
> 
> 1. Determination that there are no holes. Presence of "holes"
>    will lead to the mechanisms not being used (but implemented)
> 
>    or determine that there are no holes which will lead
>    to testing nightmares.
> 
> 2. Ensure interoperability among implementations
> 
> I hope this does not sound like I am asking Julian to do
> my work for me. But it is better hashed out and debated
> in one place.
>

---

From: [email-masked]
Date: Fri, 9 Mar 2001 17:44:43 +0200

David,

If you mean a complete formal description (including state charts) the last
complete description I've seen was the SNA manual and that was many years
ago (and included hundreds of pages on recovery alone).  I've tried to go
into enough detail so that an implementation should be possible and given
the amount of options possible I am afraid that either we give them all and
that is an inordinate (and wasteful) amount of work. None of the major
TCP/IP protocols have it and they have all added details in a pragmatic
fashion.

The same thing can be claimed for the whole protocol  not only for
recovery.

If anybody has a specific suggestion about something that is missing or a
another structure for the recovery chapter (in addition or instead the
two-dimensional approach that I have attempted) and would not require me to
write detailed recovery pseudocode (I could be amenable to write a rough
pseudocode skeleton for the recovery) I am ready to listen.

Regards,
Julo

[email-masked] on 09/03/2001 02:33:52

Please respond to [email-masked]

To:   [email-masked], [email-masked]
cc:
Subject:  RE: description of recovery mechanisms

--David

---

From: [email-masked]
Date: Fri, 9 Mar 2001 17:49:46 +0200

Somesh,

I would appreciate if your suggestions could be more concrete.
In general terms I feel that I have enough details to proceed to
implementation.
If you feel otherwise please tell me what exactly you are missing.

As I said before - If you expect an SNA manual you will probably not get
one.

Regards,
Julo

"Somesh Gupta" <[email-masked]> on 09/03/2001 03:19:23

Please respond to [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: description of recovery mechanisms

Julian,

My message is in no way an attack - above or below the
belt.

I am taking an implementor's view of things which by
necessity is detail focused, and likes to avoid
interoperability issues, testing uncertainty and
speculative processing among others.

It is a different view than others (you may or may not fall
in the category) who are more on the visionary side and
less detail focused (not that they cannot do as good
or better detail work).

I don't think the level of detail in the document
is enough at present.

Regards,
Somesh

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 08, 2001 3:28 AM
> To: [email-masked]
> Subject: Re: description of recovery mechanisms
>
>
>
>
> That was sort of under the belt. There will always be peple out there
that
> any amount of descrption is not enough.
>
> Julo
>
> "Somesh Gupta" <[email-masked]> on 08/03/2001 05:23:53
>
> Please respond to [email-masked]
>
> To:   [email-masked]
> cc:
> If the rest of the working group does feel that the level of
> detail in the spec is enough and the rest is an "exercise
> for the reader", I will accept that.
>
> Thanks,
> Somesh
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: [email-masked]
Date: Fri, 9 Mar 2001 18:22:14 +0200

Marjorie,

Examples is one concrete item that I can understand is missing.
And I will try to provide examples (or complete scenarios) in pseudocode in
06

Over specify - I think that is very bad.

Recovery can't result in too many interoperability issues since the number
of active elements we have for recovery is limited and the actions one has
to follow when issuing or receiving those are simple.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]> on
09/03/2001 03:01:11

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <[email-masked]>

To:   [email-masked]
cc:

More than just a description is necessary.  I believe the proliferation of
options regarding recovery will make for an interoperability nightmare
similar to early iterations of Fibre Channel protocols.  Too many options
and too much ambiguity result in too many conflicting interpretations.  We
need to simplify, remove options, over specify with examples.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 08, 2001 4:34 PM
> To: [email-masked]; [email-masked]