Subject: RE: One last last call comment

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 18 Aug 2000 14:14:27 -0700

I had a very similar comment on the GSMP spec. I was wondering if
the Service Model Definition could be part of a separate draft
instead of the GSMP spec. This would help reducing the size of
the GSMP spec and make it easy to extend the Service Model at a 
later time.

Regards,
Hormuzd.

-----Original Message-----
From: Jaroslaw Sydir [mailto:[email-masked]]
Sent: Friday, August 18, 2000 1:25 PM
To: [email-masked]
Subject: One last last call comment

I have a comment concerning document organization of the GSMP spec. The
GSMP document 
combines the definitions of the generic and technology-dependent parts
of the
protocol. Besides making the spec very large, this means that either,
the spec gets revised every time that GSMP is applied to a new
technology, or that some technologies are dealt with in the main spec
and some are dealt with in addendums. This would probably be more
manageable if the
spec dealt only with the generic parts and there were separate documents
for each of the technologies. This is basically an editorial change,
albeit a big
one.

Jerry Sydir

---

From: "Avri Doria" <[email-masked]>
Date: Fri, 18 Aug 2000 17:52:33 -0400

Hi,

I too have been somewhat troubled by the size and complexity
of the specification and will definately look at trying to
separate it into smaller, more focused drafts.  As  Jerry says this 
is largely an editorial exercise, but such an extensive one that
it would demand (in my opinion) a renewed WG last call.  It will 
also take several weeks to get done because it is a huge task.

On the service model issue.  Some of the service model is generic,
and I would be inclined to leave it in the general spec.  And part
of the model pertains to specific technologies and probably belongs
in the protocol domain sp;ecific docs, i.e. ATM service models with 
ATM info, FR service models with FR models.  I think that putting
them all into a service models draft would have the same update
risk as the full specification currently has.

Before actually embarking on this task, I would like to hear some
more feedback from the WG.

Incidentally, making this change would also require significant 
changes to the applicability draft and therefore this would probably 
also be submitted to a renewed last call.

a.

-- 

Avri Doria
+1 401 663 5024

---

From: "tom worster" <[email-masked]>
Date: Fri, 18 Aug 2000 18:53:22 -0400

regarding separating datalink specific parts: i think this will
make matters worse. i imagine implementing from the gsmp specs on 
a switch like ennovate's envoy 1600: all of the datalinks are 
relevant. dealing with several intricately cross-referenced specs 
would be a nightmare. also, separating out these would be 
enormously complex. the resulting pile of specs would be way
more complicated that today's single doc. i doubt that it
would be easier for an implementer to follow even if they were
using only one datalink type since instead of ignoring certain 
parts of the current spec they would have to cross reference the 
docs which is not easier.

i agree that gsmpv3 is long but that reflects the complexity of
switches as did the length of the vsi spec. but the suggested
edit is a huge and complex job that would not, in my view, 
bring any benefit.

removing the service model would mot be quite so hard but would
also bring no benefit since it is part the default qos config.
the spec has to go somewhere: locating it in a separate doc 
increases the total word count of the gsmp spec compared to
a separate chapter.

and those suggesting such huge editing jobs might like to consider
volunteering to supply the wg with revised text so that we could
evaluate if it really is an improvement.

c u
fsb