Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

If the authentication container is purely for augmentation I don't think 
we need a "security" if-feature on the security container, instead I 
would opt for an "encryption" if-feature on the encryption container. If 
someone supports authentication then it will be augmented by another 
model and the lack of such model is a clear indicator that no 
authentication is supported.

As an native v6 only network I would like to see an if-feature for ipv4 :)

    kll

On 20/04/16 09:42, stephane.litkowski@orange.com wrote:
>> What is authentication used for? Seems to be an empty container.
>
> We do not spend a lot of time on security part, so there is some adjustment to do.
> The idea of authentication container was in case customer using an authenticated access type (PPP for example) and then could provide its own password.
> The container was for the moment here just for augmentation purpose. But we can keep it, remove it, add more in, depending on feedback.
>
> Thx
>
>
> -----Original Message-----
> From: Kristian Larsson [mailto:kristian@spritelink.net]
> Sent: Tuesday, April 19, 2016 16:36
> To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; l3sm@ietf.org
> Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana'
> Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model
>
>
>
> On 19/04/16 14:17, stephane.litkowski@orange.com wrote:
>> Hi,
>>
>> We will not support all containers of the model but most of them.
>>
>> Now in term of model usage, two main usages :
>> - customer is using a portal to order the services, in this case there
>> is no need to advertise any deviation, as the REST or Netconf client
>> is  also managed by the provider (client is the portal)
>> - Provider opens API to customers :
>> 	- customer is able to use directly L3SM using REST or Netconf : deviations need to be advertised.
>
> Right, I agree. I'm convinced the first model, with a pretty web UI will be the main interface but I'm hoping that the second model will gain some traction as well. With more FOSS tools around NC/RC/YANG it certainly could and why not eliminate one step of weakly modeled data.
> Often the customer has an internal structure for what they want, like addresses of all satellite offices, which they then convert to Excel and send to the provider who will convert it to something else. This model could remove those weakly modeled steps.
>
>
>> You will find attached a quick exercise (so I probably missed some) on what could be the features in the model tree. Features are identified between {}.
>> For some identities, we would need features : YANG 1.1 needed.
>> Just to start the discussion.
>
> Good start, I actually began looking at this but you were much faster.
> We have made almost the exact same choices :)
>
> What is authentication used for? Seems to be an empty container.
>
>      kll
>
>
>> -----Original Message-----
>> From: Kristian Larsson [mailto:kristian@spritelink.net]
>> Sent: Tuesday, April 19, 2016 13:57
>> To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise';
>> l3sm@ietf.org
>> Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana'
>> Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model
>>
>>
>>
>> On 19/04/16 12:13, stephane.litkowski@orange.com wrote:
>>> The main issue with features is to define what should be a feature ,
>>> and what is in the base and I'm afraid that we could fall in infinite
>>> discussions.
>>
>> Okay, sure, I can see how that is a non-trivial discussion but it's certainly not an impossible one. Instead you are advocating for the extreme opposite and not have any if-features at all, which results in a model so big that I will have to spend more time writing a deviation file for it than it would take me to write a new model. Okay, I'm exaggerating a bit but virtually all providers will define a deviation which I think means the model is fundamentally broken. Having deviations shouldn't be the normal state.
>>
>> Does Orange support all those PE-CE protocols? Do you do encryption?
>> Will you not have any deviations?
>>
>> Kind regards,
>>       Kristian.
>>
>> ______________________________________________________________________
>> ___________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> L3sm mailing list
> L3sm@ietf.org
> https://www.ietf.org/mailman/listinfo/l3sm
>