Re: Requirements

Hello Anthony,



> Regarding:
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be considered to be eliminated."
> My understanding of the intention is that it is sufficient to apply the existing security mechanisms/protocols to protect the DMM entities.
> Ideally, we don’t want DMM to add new security risks.
> Yet, DMM can introduce new DMM entities, which can be vulnerable to security risks, and it is necessary to protect the new DMM entities.
> So we basically don’t want DMM to introduce new security risks that cannot be handled with the existing security mechanisms.
>  
> If the wording “considered to be eliminated” does not clarify the above, how about the following:
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be eliminated."
>  
> Or, can you come up with better text prior to Friday. I am trying to close all requirements issues prior to the meeting on Friday to enable the wg to move to the next step.

I recommend we delete that sentence. It's not easy to understand. And if I try hard to understand, what I understand does not make sense.
It sounds like the following:
- There are already security solutions applied to legacy/existing/non-DMM solutions.
- Those solutions must be sufficient for securing DMM solutions.
- In other words, DMM solutions must be designed in such a way that they must not require any new security solutions.

That does not make sense, IMHO.
Obviously, we'd like to minimize the work. We prefer not having to design additional stuff to secure DMM solutions.
But we cannot mandate that.
We shall not block solutions that may require additional security mechanisms. We can discourage that, but not prohibit.


>  
> Regarding your comment on the helpful references, I understand that there are many other individual drafts in the solution space. I did recently accept a prior comment to add the coloring reference. Yet now if we continue to respond to requests to add references to the individual drafts, it will not end. With the many individual drafts in the solution space, I hope the wg will have drafts that will merge/incorporate many solution drafts in future. May I now ask all the authors of the individual drafts to kindly wait for such future wg draft to consider what solutions to include/exclude?

I'm fine with that.
I saw two drafts referenced in the I-D which are complemented by two other drafts, hence I proposed them. It's OK if you don't add them.

Alper





>  
> H Anthony Chan
>  
> From: [email protected] [mailto:[email protected]] On Behalf Of Alper Yegin
> Sent: Monday, November 04, 2013 10:20 AM
> To: dmm
> Subject: [DMM] Requirements
>  
> Hello folks,
>  
> Here I have two comments on this document.
>  
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be considered to be eliminated."
>  
> I don't quite understand what that means. 
>  
> "Infrequent node mobility coupled with
> application intelligence suggest that mobility support could be
> provided selectively such as in [I-D.bhandari-dhc-class-based-
> prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
> the amount of context maintained in the network."
>  
> Two more related work references that are complementary to the ones already provided are:
> - draft-yegin-dmm-ondemand-mobility-00
> - draft-liu-dmm-mobility-api-01
>  
> I recommend we include these references as well.
>  
> Alper
>  
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm