Re: [ncrg] Meeting Notes from Today's NCRG Call

On 5/14/2013 1:02 PM, Michael Behringer (mbehring) wrote:

> I think we agree. Obviously the framework will not be able to be exhaustive; I would like to define categories, and a list of examples in each category, with a brief discussion. Deeper analysis of a single metric, or exhaustive trade-off discussions should be in separate documents.
>
> I guess the question is where we draw the line. Open for discussion. Your cases are right on the border: As they are, they could be going into either, as I see it -  a bit more compact in the framework, or a bit more extensive in a separate doc.
>
> Do you agree?

I like the idea of first defining complexity "categories" -- this way we 
are more likely to have a common ground when discussing complexity. 
Right now it seems that different people may have different definitions 
and use different terms, which could be confusing in discussions. I 
think the best place to do this is in Section 3.2.

(If we are not able to "define" the categories at this stage, at least 
we can have some short descriptions of the characteristics of each. )

I also suggest to separate "complexity" with its "trade-offs". For 
example, in my opinion cost itself is not a form of complexity, but 
could be a trade-off with complexity. The same applies to reliability, 
perhaps. It would be good if we can make the distinction more clear.   
What we can probably do is that, after we defined the various complexity 
categories, we can separately define the various trade-offs with 
complexity.

>
> On the "categorisation" we need to think whether this is reasonably possible. Today I was looking at all the metrics mentioned in both documents; they range from very high-level ones like "cost" or "scalability" to much more specific ones like "control plane state". We could probably come up with even more deep metric, such as "peer state for IPsec tunnels" or whatever. Where do we draw the line? Does it make sense to list very high level metric alongside really detailed ones? Not clear to me right now... Ideas?

I think the ideal metrics should be at the right level of abstraction, 
not too vague nor detailed.  Right level of abstraction means the  
metrics can apply to a large number of scenarios and mechanisms, yet 
remain quantitative.  ( e.g., "peer state for IPsec tunnels" seems a 
little too detailed to me as it only applies to the single scenario of 
setting up IP tunnels. "scalability" on the other hand is too vague 
since it is only qualitative. ).

-Xin

>
> Michael
>   
>> My 2c.
>>
>> Alvaro.
> _______________________________________________
> ncrg mailing list
> ncrg@irtf.org
> https://www.irtf.org/mailman/listinfo/ncrg