Re: [L3sm] Next Step of RFC8049

[David Ball <[e-mail]>]

Hi Qin,

You have cycled this round to the start of the thread. :)  There must be 
some out-of-band way of identifying and authenticating the customer from 
whom the request is being received, otherwise customer foo could request 
a service for customer bar just by filling in a different value for this 
leaf in the model!  You are right that the VPN service is a list, but a 
given customer should only ever be able to use the model to access their 
own services, they should not be able to access services for any other 
customer.

     David

On 28/06/2017 03:37, Qin Wu wrote:
>
> David:
>
> A few thoughts and comments below.
>
> *发件人:*David Ball [mailto:[e-mail]]
> *发送时间:*2017年6月27日19:53
> *收件人:*Ogaki, Kenichi; [e-mail]; Qin Wu; 
> [e-mail]
> *主题:*Re: [L3sm] Next Step of RFC8049
>
> Thanks Kenichi - there is one of your answers that I'm still confused 
> about, see below:
>
> On 26/06/2017 04:23, Ogaki, Kenichi wrote:
>
>             4.   Under the VPN service, there is a leaf for the
>             customer name.  If the model is supposed to represent the
>             request from a customer to the SP, I would have thought
>             the customer name would be known out-of-band, e.g. from
>             the AAA for the request?  It would be bad if one customer
>             could request things for another customer by filling in a
>             different customer name in the model!
>
>                  [KO] A customer can only access the model instance of
>             that customer. Please see section 10.
>
>             [DB] Yes exactly - if a customer can only access their own
>             instance of the model, why does the customer name need to
>             be specified within the model?  You already know you are
>             dealing with that customer's instance of the model.  It
>             seems like the customer-name leaf is unnecessary?
>
>             [KO] As common usecases, a VPN service is provided not
>             only by Tier 1 providers, but also by Tier 2 providers or
>             IT divisions of enterprises in order to provide their own
>             end users by using a Tier 1 provider's VPN service. Such
>             customers usually requires this kind of attributes for
>             their management purposes.
>
>         [DB2]
>
>         I didn't really follow this, sorry.  The module contains the
>
>         information that needs to be sent from the customer to the SP,
>         right?
>
>         If the customer using the model (i.e. the Tier2 in your above
>         example)
>
>         needs to track which of their own customers the service is
>         for, that's
>
>         something that's internal to them, isn't it?
>
>     [KO3] Yes, that's internal to them, but they (i.e. our customers)
>     really request and are currently using this. Then, we need to
>     model this.
>
>
> Perhaps I am misunderstanding the scenario.
>
> If I understand correctly, the case is where the yang is being used 
> between a Tier2 provider (lets call them T2-telecom) and Tier1 
> provider (lets call them T1-networks).  In other words, from the 
> perspective of the RFC and the yang module, T1-networks is the SP and 
> T2-telecom is the customer.
>
> T2-telecom has their own customers call them (foo-bank, 
> bar-supermarket and baz-advertising).  Whenever T2-telecom orders a 
> new VPN from T1-networks, they want to record, in their internal 
> systems, which of their end customers the new VPN is for.  Of course 
> there is probably a lot of other information they want to store in 
> their internal systems about their customers, such as contact info, 
> billing and invoicing info, trouble tickets, etc.
>
> What I don't understand is why T2-telecom would want to send the name 
> of their end-customer (foo-bank, bar-supermarket or baz-advertising) 
> to T1-networks as part of the netconf request when they order a new 
> VPN.  What is T1-networks going to do with this information?
>
> [Qin]:
>
> 1.With customer name,you could use it as a key to lookup detailed 
> customer information such as contact info, billing info if needed.
>
> 2. You forget that VPN service is defined as a list of VPN Service. 
> That is to say different VPN service could belong to different customer,
>
> Adding customer name, we could know which customer has which VPN service.
>
> 3. customer name is just defined as an optional parameter. You don’t 
> need to specify it in the case you don’t need it.
>     David
>
>
> -- 
> David Ball
> <[e-mail]> <mailto:[e-mail]>

-- 
David Ball
<[e-mail]>