Re: [Rats] Use case -> architecture document

[Schönwälder, Jürgen <[e-mail]>]

Hi,

I did also look at the use cases document (I think -04) after going
through the architecture document and I must admit that I did not find
it too helpful to understand things better. I did not see anything
architectural in there either. I guess I will read the teep
architecture next and perhaps that helps me to get a better clue.

For people like me who are not deep into this technology yet, getting
used to the rather specific terminology and concepts is a certainly a
learning effort and I think the architecture document was on its way
to get terms well defined and sorted out. Some more examples or
explanations may help the reader further and I believe this can be
achieved.

/js

On Wed, Oct 09, 2019 at 01:55:57PM +0200, Henk Birkholz wrote:
> Hi Kathleen,
> hi list,
> 
> it would help everybody, if you could explicitly highlight what the exact
> issues wrt readability in the current architecture I-D are - always in
> comparison with the use-case I-D, if it is doing a better job in that part?
> 
> Jürgen provided a good example of what he found confusing as a first time
> reader - and that was really helpful and is resulting in ongoing work.
> 
> Please mind, not everything is fleshed out in the architecture (e.g. the
> workflows derived from the use-cases). The plan was to aim for a stable
> nucleus, address the issues raised by the list, go through adoption, and
> finish the document via the issue tracker in a structured process.
> 
> In summary, without an actual understanding why you (or others!) think the
> document is still hard to read, there is no way of compare readability later
> on also. It would be really good to get more precise feedback on that.
> 
> Viele Grüße,
> 
> Henk
> 
> 
> 
> 
> On 09.10.19 13:31, Kathleen Moriarty wrote:
> > Hi Frank,
> > 
> > Thank you for voicing your concern.  I think some may hold off until the
> > updates are provided, but please do voice your opinions.  I agree that
> > this work is too important and as such, readability is a high priority.
> > If you read through the TEEP and SUIT architecture drafts, they are
> > quite easy to follow and understand.  That is critical for wide spread
> > adoption.  We may be able to find a balance, but I think this exercise
> > may speed progress as we have not decided to adopt this draft yet as a
> > working group item.
> > 
> > As it stands, the use case document is not an architecture document, but
> > it could be shaped as such and I'd really like to see if we can do that
> > in short order to have a comparison prior to an adoption call.
> > 
> > Best regards,
> > Kathleen
> > 
> > On Wed, Oct 9, 2019 at 6:53 AM Xialiang (Frank, Network Standard &
> > Patent Dept) <[e-mail]
> > <mailto:[e-mail]>> wrote:
> > 
> >     Hi Kathleen,____
> > 
> >     __ __
> > 
> >     I am very concerned with this new direction and I strongly object.____
> > 
> >     __ __
> > 
> >     Current architecture draft goes through a lot discussions and
> >     reaches many consensus. Right now, it really helps IETF (Teep for
> >     example), FIDO, TCG and many others. The only issues are on
> >     readability, the standards track and the completeness (e.g.,
> >     passport and background check are still missing). It is an very good
> >     document and correct terminology is very important for remote
> >     attestation.____
> > 
> >     __ __
> > 
> >     About use cases document, Its goal is just to clarify a sample list
> >     of scenarios that remote attestation can apply to and then deduce
> >     the requirements and the following concrete protocol drafts. It is
> >     not fit to be an architecture.____
> > 
> >     __ __
> > 
> >     The current architecture is too important for telecom and network
> >     equipment vendors and service providers. I have strong doubts that
> >     current EAT and OTrPv2 alone is suitable for the (virtualized)
> >     network infrastructure situation.____
> > 
> >     __ __
> > 
> >     B.R.____
> > 
> >     Frank____
> > 
> >     ____
> > 
> >     __ __
> > 
> >     This e-mail and its attachments contain confidential information
> >     from HUAWEI, which is intended only for the person or entity whose
> >     address is listed above. Any use of the information contained herein
> >     in any way (including, but not limited to, total or partial
> >     disclosure, reproduction, or dissemination) by persons other than
> >     the intended recipient(s) is prohibited. If you receive this e-mail
> >     in error, please notify the sender by phone or email immediately and
> >     delete it!____
> > 
> >     __ __
> > 
> >     *发件人:*RATS [mailto:[e-mail]
> >     <mailto:[e-mail]>] *代表 *Kathleen Moriarty
> >     *发送时间:*2019年10月8日19:25
> >     *收件人:*[e-mail] <mailto:[e-mail]>
> >     *主题:*[Rats] Use case -> architecture document____
> > 
> >     __ __
> > 
> >     Hello!
> > 
> >     I read through the latest version of the ‘use case’ document
> >     yesterday and found it very easy to read and understand, meaning I
> >     think it is written well and could be easily understood by many
> >     without having to climb up a learning curve. ____
> > 
> >     __ __
> > 
> >     First, this could be a very useful document to register claims for
> >     the use cases.
> > 
> >     Second, if the workflow for the passport and background check were
> >     added and put in terms of the open trust protocol v2 from TEEP, we
> >     have a fairly nice architecture document that’s easy to read and may
> >     gain adoption.  The workflows cover the various interactions between
> >     roles and TEEP has actively broken up OTrP in v2 to
> >     accommodate using EAT tokens, this would help create that link and
> >     make it very clear.
> > 
> >     The other thing I like about the use case document and think we
> >     should expand on is the references to other work items.  This makes
> >     it an architecture document that maps out the full plan of the WG.
> > One like that was extremely well received by all the ADs that don’t
> >     like informational/helpful documents.
> > 
> >     I’m a bit nervous with the terminology being defined and would love
> >     to see something like this that’s simplified and more easily
> >     adoptable. ____
> > 
> >     __ __
> > 
> >     I appreciate the work done to improve the architecture document, but
> >     I do think the structure changes to the use case document as
> >     suggested could result in an easier to understand (and therefore
> >     easier to adopt) document.____
> > 
> >     __ __
> > 
> >     While the architecture document is more readable, I think we can do
> >     better.  Adoption is important and our timeliness matters a lot for
> >     this work.  EATs can be used for may use cases with OTrPv2, so let's
> >     keep it as simple as we can.
> > 
> >     Thoughts are appreciated.
> > 
> >     Best regards,
> >     Kathleen-- ____
> > 
> >     __ __
> > 
> >     Best regards,____
> > 
> >     Kathleen____
> > 
> > 
> > 
> > -- 
> > 
> > Best regards,
> > Kathleen
> > 
> > _______________________________________________
> > RATS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rats
> > 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>