Subject: RE: Need to standardize defs...

From: Jacques Rajchgod <[email-masked]>
Date: Thu, 23 Aug 2001 15:56:53 -0500

Another example I am grappling with is the def "IPSP". In one case it stands
for "IP Signaling Point" and in another - "IP Server Process" both of which
have different meanings:
  a.. In SUA-06, it's "IP Server Process - A Process Instance of an IP-based
application...Essentially the same as an ASP except no SG is used".
  b.. In M2PA -02, it's "IP Signaling Point - An SS7 Signaling Point with an
IP Connection, used for SS7-over-IP".
The acronym is used everywhere in SIGTRAN specs and in various discussions
and I have to be on guard at all times to make sure I have captured the real
"IPSP"  - the one being the real subject of the discussion...At times, even
that is difficult, as I find-out that various people do not understand each
other because one thinks "A" while the other - "B"...

We need consistence to make Tech life easier...
Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-1487
E-mail: [email-masked]

  -----Original Message-----
  From: Schantz, John [mailto:[email-masked]]
  Sent: Thursday, August 23, 2001 9:53 AM
  To: sigtran
  Subject: RE: Need to standardize the defs for "AS" and "ASP".

  Actually this is a great topic because AS and ASP are the most confusing
concepts in all of these documents.  I know I wrestled with for a while and
so have many others, and people are still struggling with them.

  The name is very misleading, Application Server.  It is not an application
and it is not a server.  The real applications/servers sit on top of the
protocol stack, away from any UA.  Many of the documents imply that it is a
real signalling node or at least part of one, this is perception is wrong
too.

  Actually, I think the definition that you quote from SUA might be the
closest one:  "...a logical entity serving a specific routing key".  You can
also dig this meaning out of M3UA.

  Maybe we can generate a good definition from the facts about AS:

  1)  Has a 1-1 correspondence with an RK (i.e., it is bounded by a single
RK and the traffic defined by the RK),
  2)  It only exists within the specific UA in question,
  3)  Its traffic is handled by a collection of SCTP end-points, these have
been defined as ASPs.  AS has also been defined as the collection ASPs
serving this specific set of traffic.

  I can only conclude that an AS is only a routing concept (logical entity)
association with a specific set of signalling traffic (RK) that only exists
within the specific UA in question and has an assigned collection of SCTP
end-points handling it traffic.

  John
    -----Original Message-----
    From: Jacques Rajchgod [mailto:[email-masked]]
    Sent: Wednesday, August 22, 2001 2:51 PM
    To: sigtran
    Subject: Need to standardize the defs for "AS" and "ASP".

    Hi, SIGTRAN...

    In all the IETF docs related to SIGTRAN, there is a sore need to
standardize and "make-it-stick" -- the following defs that relate to the
abbreviations "AS" and "ASP". The otherwise lack of such standardization
invites errors of interpretation. Taking a look at SUA and IUA, one can
easily take it that an "AS" is a database in SUA (section 1.2 -
terminoilogy) and then again a real Process (not a database) in IUA - same
section.

    An "AS" is the same logical "AS" everywhere. Its def must be consistent
across all docs.
    If we have in mind to denote different services or functions (such as a
database in one case whilst a real Process - in another) then we need to
define them exactly per their intended individual functionality, but we may
not otherwise dump everything inside the same basket of "AS" or "ASP". There
is a need for careful consistency across all IETF operations. If we define
an "AS" in IUA as "A logical entity serving a specific application instance"
and bring examples of such def as an MGC, then we cannot define "AS" in SUA
as "...a logical entity serving a specific routing Key with example of a
Virtual IP database..." as that invites confusion at Planning and testing
orgs!

    The first def "A logical entity serving a specific application instance"
is the correct one and need be carried across all IETF docs with
consistence.

    If a def has a multiplicity of meanings, then such multiplicity need be
carefully stated and described in the "Terminology" sections of IETF's.
Usually, the IETF does an excellent job at defining or stating the meanings
of terms. We want to keep it that way. Consistence.

    Thanks,
    Jacques Rajchgod
    MCI Worldcom
    Next Generation System Evaluation
    Tel: [972] 729-1487
    E-mail: [email-masked]

    ---
    You are currently subscribed to sigtran as: [email-masked]
    To unsubscribe send a blank email to
[email-masked]
  ---
  You are currently subscribed to sigtran as: [email-masked]
  To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Jacques Rajchgod <[email-masked]>
Date: Thu, 23 Aug 2001 16:49:41 -0500

I have a suggestion for the alleviation of ambiguous and/or dual-meaning
defs. Suggestion is as follows:

  1.. That a database of terms/defs be started and maintained at all times
by all IETF chairs or a designated one.
  2.. Before attempting to define a new def, or attempting to re-use a
potentially-existing one in a particluar context, that the author of a such
doc first check the (to-get-born) database for the existence of such def.
One of two actions would trigger from such database search result:
    a.. Def is found as already-existing.
    b.. Def is not found.
  3.. If def is NOT found, author is free to generate a required def.
  4.. If def is YES found as already-existing, then the author may NOT use
or re-use the exact def in the same context in his/her new doc.
    a.. If author does wish to re-use the already-existing def for a
particular needed context such that author feels he must use the exact, same
abbreviations/acronyms, that a modification be done, so the already-existing
def acquires a different meaning. Example:
    b.. The term "SG" (Signaling Gateway) is found by a search_DB to already
exist in a def DB (database). However the author wishes to re-use that
native def (denoting a Signaling Gateway) to refer to a SG now doing
Broadband. Then, such author might COPY the already-existing def to make it
a new one ("SAVE_AS") such as "BSG" which would stand for "Broadband
Signaling Gateway - A SG used in Broadband technologies".
    c.. Another example:
    d.. A search_DB yields that the def "IPSP" already exists that denotes
an "IP Signaling Point....doing SS7-over-IP" (M2PA)
    e.. Now then, the author wishing to use the same close-proximity
abbreviations/acronym to denote an "IP Server Process" (M3UA) would COPY the
def from the DB to save it as a new one (SAVE_AS) "IPSPr" (<--Notice the LC
"r"..). Everyone would instantly pick-up the minute difference between an
"IPSP" and an "IPSPr"...and would know exactly what it is that is beingv
referred-to. How easy!
  5.. The DB would have to be empowered to refuse the re-use of an
already-existing def...It would have to do all the great things that good
and secure DB's do...
Advantages:
  1.. Very simple (Check-and-see the DB: Is the def already there?)
  2.. Secure (Cannot ever again cause ambiguity or dual meaning or wrong
meaning emanating thereof)
  3.. Order in the term/def ranks and elimination of confusion...
  4.. Efficient and time-saving (imagine the elimination of so many
E-mails...!)
  5.. Most important: An absolute clear understanding of what the def is
pointing to!
Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-1487
E-mail: [email-masked]

  -----Original Message-----
  From: Schantz, John [mailto:[email-masked]]
  Sent: Thursday, August 23, 2001 9:53 AM
  To: sigtran
  Subject: RE: Need to standardize the defs for "AS" and "ASP".

  John
    -----Original Message-----
    From: Jacques Rajchgod [mailto:[email-masked]]
    Sent: Wednesday, August 22, 2001 2:51 PM
    To: sigtran
    Subject: Need to standardize the defs for "AS" and "ASP".

    Hi, SIGTRAN...

    Thanks,
    Jacques Rajchgod

---