Subject: [sacm] Telecommunication Requirement

From: Adam Montville <[email-masked]>
Date: Mon, 3 Mar 2014 15:57:56 -0600

Xiaojun Zhuang, Minipeng Qi, Judy Zhu:

Thank you for your submission of draft-zhuang-sacm-telereq-00!  

In reviewing your submission it seems as though your several use cases would be accommodated by the existing use case document (see http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/), but that there may be additional scenarios not yet considered by the working group.  For example, the vendor providing specific baseline guidance to a specific customer is a scenario that may be abstractly covered by existing use cases, but not specifically covered. 

Can you provide additional information as to why the telecommunications use case for “security policy baseline setting” (4.1 in your submission) would not be satisfied by the use cases already covered in our working group document?  Are there considerations omitted by our use cases?  

If any of you happen to be in London for the IETF meeting, I’m sure one or more of the working group participants would be happy to meet with you for a discussion (preferably in advance of the scheduled SACM session).  We welcome your participation and hope you are able to continue your contributions to the work.

Kind Regards,

Dan and Adam

---

From: "Minpeng Qi" <[email-masked]>
Date: Wed, 5 Mar 2014 21:54:42 +0800

Dear Adam,

Pls see comment inline.(starts with "//Minpeng")

BRs,
Minpeng

-----邮件原件-----
发件人: Adam Montville [mailto:[email-masked]] 
发送时间: 2014年3月4日 20:43
收件人: $)A
Fk$*HN'*Et
抄送: [email-masked]; [email-masked];
[email-masked]
主题: Re: Telecommunication Requirement

On Mar 3, 2014, at 10:24 AM, $)A
Fk$*HN'*Et <[email-masked]> wrote:

> Dear Adam,
> 
> Thanks for your reviewing and comments.
> 
> For "security policy baseline setting", a part of our concerns are coming
> from the following fact: 
> For the telecommunication, most features are standard but the
implementation
> are free designed by vendors. As a result, for a specific operator, it
would
> own different kinds of equipments/devices from different vendors to
achieve
> one feature. It implies that there are different implementations related
to
> same security requirement. We can't set a fixed detail baseline for all
> vendors. So, for a given security policy baseline, it should contain two
> parts: one is fit for all vendors devices, and the other should flexible
> alternatives to cover all detail implementations from different vendors.
> For this issue, I fail to find any related information from existing use
> case document. Do I miss anything related this issue?

The way I$)A
!/m reading what you
!/ve written is that there are many ways to satisfy a given business
function using equipment from a variety of vendors in a variety of
configurations.  The implication appears to be that the ability to specify
baseline configurations should be flexible enough to handle the scenario
where a single business function might be satisfied by a variety of vendors
!/ equipment.  

//Minpeng: There has slight different. Vendors have free to design their
implementation. However, the flexible should be limited into some extent.
For example, for a feature, it contains two parts: one for common and the
other for flexible. However, for the flexible part, there are some
pre-defined alternatives, like alternative A, alternative B, alternative C.
Vendors can choose to implement A or B or C freely, but they should choose
one of them to implement.

If that is about right, then I believe the requirements document does cover
such flexibility by way of GEN-001 in section 2.2. which states, $)A
!0the data models, protocols and transports defined by SACM must be
extensible to allow support for non-standard and future extensions.
!1  The vendor-specific details might be considered 
!0non-standard
!1 in this sense.

//Minpeng: Based on the clarification, it may not be suitable to say it is
“non-standard”. So whether it has been covered or not should be
reconsidered.

> 
> BTW, I'm in London now. I'm also happy to talk with you or anyone else. 

Unfortunately, I was unable to make the trip to London.  Dan Romascanu, Dave
Waltermire, Nancy Cam-Winget, and other primary working group contributors
are present, however, and may be able to meet with you to further discuss
any special needs the telecommunications industry might have.

> BRs,
> Minpeng
> -----$)A
SJ<~T-<~-----
> $)A
7"<~HK: Adam Montville [mailto:[email-masked]] 
> $)A
7"KMJ1<d: 2014
Dj3
TB4
HU 5:58
> $)A
JU<~HK: [email-masked]; [email-masked];
> [email-masked]
> $)A
3-KM: [email-masked]
> $)A
VwLb: Telecommunication Requirement
> In reviewing your submission it seems as though your several use cases
would
> be accommodated by the existing use case document (see
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/), but that
there
> may be additional scenarios not yet considered by the working group.  For
> example, the vendor providing specific baseline guidance to a specific
> customer is a scenario that may be abstractly covered by existing use
cases,
> but not specifically covered. 
> 
> Can you provide additional information as to why the telecommunications
use
> case for $)A
!0security policy baseline setting
!1 (4.1 in your submission) would
> not be satisfied by the use cases already covered in our working group
> document?  Are there considerations omitted by our use cases?  
> 
> If any of you happen to be in London for the IETF meeting, I$)A
!/m sure one or
> more of the working group participants would be happy to meet with you for
a
> discussion (preferably in advance of the scheduled SACM session).  We
> welcome your participation and hope you are able to continue your
> contributions to the work.
> 
> Kind Regards,
> 
> Dan and Adam
> 
> 
>

---

From: Adam Montville <[email-masked]>
Date: Wed, 5 Mar 2014 08:01:15 -0600

> one of them to implement.

If the data/information models this working group leverages are flexible, extensible, and scalable, then we should accommodate the systems you reference.  If the system has some set of "configuration items" or "configurable knobs" then we should be able to cover it with our data/information models.  

Presuming our models suitably represent the telecommunications equipment, then what it seems you're asking for will also be covered by the capabilities already described in the use cases and/or requirements for this working group.  It seems that, for each predefined alternative (A, B, or C above), there could be a policy created.

Adam