Hannes Tschofenig | 17 Jan 09:58 2006

Re: Review Comments

hi pekka,

please find a few comments below;

Pekka Savola wrote:
> Hi Hannes -- thanks for comments, hopefully this will trigger some very 
> useful discussion.. inline,
> On Mon, 16 Jan 2006, Hannes Tschofenig wrote:
>> - incorporate the threats draft into the framework draft.
>> if you only focus on the above-described case then the protocol is
>> pretty simple and the security threats should focus on the protocol you
>> want to develop. you don't want to describe all the security threats
>> that can happen in a network.
> ....
>> - make the framework document shorter. try to make it as short as 
>> possible.
>> make the long story short: "you want to configure policies at the end
>> host to perform firewalling functionality." that's it. we don't need to
>> give a tutorial about firewalls. it is a deployment choice whether you
>> want to use firewalls at the end host, at all network elements or only
>> at the edges (or as a combination of all this). this is not relevant for
>> the goal you try to accomplish.
> I think I agree with the main thrust of your comments.  However, I'm not 
> certain folks here have a clear picture on what each document should 
> contain..
> You seem to think there is no need to write a problem statement and/or 
> justify why the work is needed, just go straight to the framework (and 
> the threat model).

i think it is good to have a problem statement section in the draft. it 
should, however, be as short as possible and focus on the aspects you 
want to work on.

>  That justification takes a lot of space in the 
> framework document as-is, and as it's a bit introductory (and 
> controversial) it doesn't always generate warm feelings..

it is in many places wrong and biased. in fact, the outcome of the work 
will be useful for both "security models". hence, there is no reason to 
argue that one model is good and the other model is bad.

> However, I believe that if we don't write about it somewhere, the issue 
> is going to come up.  Do you think that text is necessary?  If so, where 
> should it be -- a separate document?

couldn't you move the text of section 2 to the appendix (after fixing it)?

> The rest of the non-integral part of the framework is discussion of the 
> attributes of that the solution would likely fulfill.  That should 
> probably go somewhere as well, though I could be convinced it doesn't 
> need to belong to the framework document.

currently, i don't really see these parts of the solution.

> Based on this, maybe the document structure should be something like:
>  - draft-foo-distsec-background (how we got here, something about the
> problem statement etc. if needed)
>  - draft-foo-distsec-framework (generic and short, including threat model
> discussions and problem statement)
>  - draft-foo-distsec-solutionism (or whatever, which could include more 
> details
> of a possible solution)

i haven't thought about this type of structuring before. i personally 
think that the background should be in the appendix of the framework 
document. the separation between the "background", "problem statement" 
and the "framework" is quite difficult to draw.

i personally would add a requirements document.

draft-foo-distsec-solutionism could be developed later. it is still a 
bit early to discuss the solutions given that the requirements are not 
even there yet.
furthermore, i believe that such a generic solution document is quite 
difficult to write given the different (and large number of) solution 
approaches that are available.

> What's your view on where the different parts of text should go, (and if 
> any) which should simply be thrown away?