[Nsi-wg] NSI - Call Issues/agent naming

[John Vollbrecht]

I agree with Joe that this is a new concept.  I also think we have  
dealt with this naming issue for a while, and I think it important in  
how the effort is perceived by the outside community.  We also spent a  
long time discussing this during the time when Inder wasn't able to  
participate so he has not heard all the discussion.

The original decision to call each side of the interface a agent, to  
call one side the requester agent (rather than user) and to call the  
other side a Network Service agent (not provider) was one we all  
agreed on.  We changed it, in my opinion, because the name was getting  
confused with other names such that discussion became confusing - and  
the  fact that WS uses  requester - provider seemed the only  
reasonable solution - though at the time I noted that we needed to get  
approval of this from the original participants.

We didn't get approval of original participants, so we need to rethink  
this.  We have also changed other names in the meantime, so for me  
going back to requester agent and service agent on  Network Service  
Interface seems quite reasonable.

I agree that we have talked about this quite a lot - way more than I  
wish.  I would like to make a decision, hopefully tomorrow, to 1) go  
back to the original name, 0r 2) to pick a different name, or 3) to  
stick with the name we have.

John


On Dec 15, 2009, at 1:46 PM, Joe Mambretti wrote:

> >NSI are familiar and comfortable with the requester/provider  
> standards terminology.
> When this initiative began, one of the motivations was to develop an  
> architectural framework for emerging and innovative concepts - not  
> legacy formulations. This initiative should move beyond "familiar  
> and comfortable" concepts.
>
> At 12:39 PM 12/15/2009, Inder Monga wrote:
>> John,
>>
>> Since we are revisiting the naming of the agents again (and again) -
>>
>> I would like to voice support  for the current terminology of  
>> requester and provider agent by providing reference following  
>> diagram in the Web Services specifications that supports it. We  
>> should not let our experiences with the network/internet service  
>> provider color our judgement, as the applications that  we hope  
>> will use NSI are familiar and comfortable with the requester/ 
>> provider standards terminology.
>>
>>
>> Web Services Architecture
>>
>>
>>
>>
>> W3C Working Group Note 11 February 2004
>>
>>
>>
>> :
>> http://www.w3.org/TR/ws-arch/#gengag
>> <1385314.gif>
>>
>>
>>
>> On Dec 15, 2009, at 8:13 AM, John Vollbrecht wrote:
.
.
.
>>
>>>
>>> I have two issues that need to be decided for the document.
>>>
>>> 1) Naming of two sides of NSI interface.  We originally named these
>>> the requestor agent and network service agent.  This after  
>>> significant
>>> discussion, especially about the fact that we should not use  
>>> provider
>>> because it had connotations of the commercial providers.  Later we
>>> decided to go ahead and use the name provider because Network  
>>> Service
>>> Agent was confusing with other names like Network Service Actor.   
>>> Also
>>> requestor and provider are terms used by others so seemed  
>>> reasonable.
>>> The person who was most strongly against using the name provider was
>>> not on the call when we made the decision to change, and he  
>>> continues
>>> to feel strongly that it is a bad name.
>>>
>>> I think we made a decision not to use provider and should not change
>>> it without agreement from the parties involved in the decision.
>>> Therefore I would like to change the name of different sides of the
>>> NSI to something else.  Suggestions are a) requester agent- service
>>> agents,  b) client  agent - server agents.
>>>
>>> We need to determine the name in order to make the document.  I  
>>> think
>>> this is a NSI group decision, and I am hoping we can decide  
>>> tomorrow.
>>>
>>> 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20091215/20df91e0/attachment.html