Subject: Re: [Isms] isms core documents last call status

From: "David Harrington" <[email-masked]>
Date: Wed, 3 Dec 2008 19:40:30 -0500

Hi,

I am editing the tmsm document.
Tom is obviously not satisfied with the tmsm document. He thinks the
architecture document should be clearer than it is. I do not know what
I am supposed to change.

He would like much more detail about how values are transformed, but
that is extremely dependent on the specific models. The whole prefix
thing is TSM-dependent; the [email-masked] is SSH-transport-model
dependent. Moving those details into tmsm would totally violate the
whole modularity principle.

A discussion of what can be achieved by mixing and matching existing
models also seems wrong in the architecture document. We have a whole
section on "Coexistence, Security Parameters, and Access Control" that
discusses this from an architectural level.

It is my intention to ignore this email from Tom, unless you tell me
to something specific.

dbh

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Friday, September 07, 2007 10:08 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Isms] isms core documents last call status
> 
> Juergen
> 
> You are right that I have commented on tmsm and I would 
> regard my comments on
> the use of security name and security level (and I 
> deliberately do not use the
> RFC3411 terminology here) therein as technical and (as yet) 
> unresolved. Jeffrey
> has rightly pointed out that words can be found to support a 
> position - eg
> sshtm - but I think that an architecture document should be 
> clearer than that,
> particularly over the issue of values being transformed.  
> Also, it is not
> obvious what can and cannot be achieved, as with USM over 
> SSH, which currently
> appears infeasible.
> 
> The sshtm I-D is more restrictive and so is not such a 
> problem; but I can see a
> future working group trying to make sense of tmsm in the way 
> we have tried to
> make sense of eg authoritative, context engines, informs etc
> 
> Tom Petch
> 
> 
> ----- Original Message -----
> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, September 07, 2007 9:26 AM
> Subject: [Isms] isms core documents last call status
> 
> 
> > Hi,
> >
> > the WG last call on the core ISMS documents has so far 
> resulted in the
> > following reviews (let me know if the data below is incorrect):
> >
> > draft-ietf-isms-tmsm-09.txt                       BW, TP, JS
> > draft-ietf-isms-transport-security-model-05.txt   BW, TP, DR, JS
> > draft-ietf-isms-secshell-08.txt                   BW, WH, JS
> >
> > [BW] = Bert Wijnen
> > [TP] = Tom Petch
> > [DR] = Dan Romascanu
> > [JS] = Joe Salowey
> > [WH] = Wes Hardacker
> >
> > While some very good people reviewed the documents, it would
surely
> > not hurt to have some additional reviews. If there are more people
> > here who have read the documents but kept silence since they did
not
> > have an issue to post, please let me know. If you did not manage
to
> > read the documents due to vacation time, please still consider to
> > review the documents and send comments by the end of next week
> > (September 15th) or contact me if you need more time.
> >
> > I am now going through the discussions in detail in order 
> to classify
> > the issues that were brought up to see which are editorial, 
> which are
> > technical and if there are any issues where the resolution is not
> > clear. Once I have assembled this list, I will post it here for WG
> > review and ask Dave to revise the documents. I hope we can 
> deliver the
> > core documents to the IESG soon.
> >
> > Since I have to write up the paper work for submission to 
> the IESG, I
> > am also interested to hear about people planning to implement or
> > experiment with the ISMS technology. While there have been several
> > indications in the past, it surely helps me if people interested
to
> > implement/experiment contact me again so that I have an up-to-date
> > view on things.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen,
Germany
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> >
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Dec 2008 11:46:46 +0100

> whole modularity principle.

I agree.
 
> discusses this from an architectural level.

I agree.

/js

Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 05 Dec 2008 12:09:34 -0800

>>>>> On Wed, 3 Dec 2008 19:40:30 -0500, "David Harrington" <[email-masked]> said:

DH> Tom is obviously not satisfied with the tmsm document. He thinks the
DH> architecture document should be clearer than it is. I do not know what
DH> I am supposed to change.

Although I do think the documents are a bit hard to read if you're not
familiar with the history, I don't think that changes can be made that
would significantly improve things.  The IETF has constantly had issues
with documentation of modular systems.  We tend to define lots of small
documents that interrelate but we optimize for future
expandability/replacability over readability.  E.G. we must be able to
have the TMSM and SSHTM documents work with a new TSM2 document.
Because of this it means things are hard to describe in one place.

DH> He would like much more detail about how values are transformed, but
DH> that is extremely dependent on the specific models. The whole prefix
DH> thing is TSM-dependent; the [email-masked] is SSH-transport-model
DH> dependent. Moving those details into tmsm would totally violate the
DH> whole modularity principle.

And that's a prime example.  The "ssh:" prefix is, and should be,
specific to just the TSM document.  The joe@ prefix is very ssh specific
and shouldn't go into the other documents.  I can see how this can lead
the reader into a bit of confusion until they shuffle through it all.
But to add the details into the other documents would be wrong, IMHO.

DH> It is my intention to ignore this email from Tom, unless you tell me
DH> to something specific.

I agree with this decision.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms