[Nsi-wg] clearer naming for service definitions

[Guy Roberts]

Hi Jerry,

In my mind the important part of this suggestion was to have a naming scheme that clearly distinguish between the capabilities, request and instance.  At the moment I don't think we have this.  I am happy with using SD, SR, SI or SP, SR, SI as long as these are clearly defined in your service definition text and consistently used by the group.

Guy
From: Jerry Sobieski [mailto:jerry at nordu.net]
Sent: 30 March 2011 22:55
To: Guy Roberts
Cc: nsi-wg at ogf.org
Subject: Re: [Nsi-wg] clearer naming for service definitions


On 3/30/11 12:45 PM, Guy Roberts wrote:
Jerry,

As discussed in today's NSI call a clearer naming scheme would be helpful for service definitions, the following is proposed (with thanks to Inder and Tomohiro):

Service Capabilities Definition (SDC) -  This is often referred to as the 'service definition', so from Jerry's document: 'The Service Definition (SD) is a machine readable textual document that identifies each attribute of the service and the range of values that attribute will allow'.  ... and I think defines a default value?

Service Request Description (SRC) - this is a request for a specific instance of a service.  It is created by the Requester Agent when it assigns desired values to each of the attributes described in the SDC.  The SRC is sent from the RA to the PA in a Connection Request.

Service Instance Description (SID) - this is a description of an actual service instance, the attribute values reflect the values chosen and confirmed by the Provider Agent.
Would these terms help clarify your service definition document?
Ahem...I think my terms are perfectly clear thank you very much.
:-)

I am reluctant to change from "Service Definition."  We have been using the term for over a year in the NSI WG.   And I can reference documents 5+ years old referring to "service definitions", and even the GN3 BoD documents reference "Service Definitions" in this manner.

In the NSI context, the sd document *defines* the scope of the service - the attributes and their ranges.   These are not really "capabilities" each themselves - they in fact define a single [service] capability, or service.   The sum result of defining all of these attributes is to bound - or "define"-  a single service capability.

If a network offered two distinct services, then I would be more inclined to say there are "two service capabilities" in that network - or "two services".

So while I see a relevance, I don't really think "Service Capabilities"  is a better term.

I could go with "Service Profile" (this isn't too bad...), Service Request, and Service Instance.  SP, SR, SI.   Each of these have a set of Attributes - SPA's, SRA's, and SIA's.

??
Jerry


PS:  Is some of the unease based on the "Connection *Service* protocol" terminology?   IMO, the protocol does not define the service  - it just provides the mechanism for interfacing with the various services (or service providers.)   Hence the Network Service Interface term.  The protocol is not the service, even if the service uses the protocol to present the service and to deliver the service....  Just trying to find why these terms are so vexing...

Guy
_____________________________________________________________________

      **       Guy Roberts, PhD     Network Engineering & Planning
    *    *                          Tel:    +44 (0)1223 371300
   *      *    City House           Direct: +44 (0)1223 371316
   *           126-130 Hills Road   Fax:    +44 (0)1223 371371
  *            Cambridge
  *            CB2 1PQ              E-mail: guy.roberts at dante.net<mailto:guy.roberts at dante.org.uk>
  D A N T E    United Kingdom       WWW:    http://www.dante.net
_____________________________________________________________________






_______________________________________________

nsi-wg mailing list

nsi-wg at ogf.org<mailto:nsi-wg at ogf.org>

http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110331/6c30d0cc/attachment.html