Re: [Rats] Use case -> architecture document

[Henk Birkholz <[e-mail]>]

Hello Guy.
hi list,

if adding the exemplary workflows before the definition of the 
principals and interactions between them is increasing the readability 
of the architecture, then yes.

I think the notion was to add them up front.

I am well aware of how the SUIT architecture looks like and it is fueled 
by the information model, because the use cases live in there and 
requirements are inferred from them. The goal in SUIT is not to create a 
shopping list of elements for the corresponding manifest, but to provide 
a valid reason why the information elements should be defined and then 
go into the manifest data model.

In SUIT, use cases in the Information Model use English language and a 
pattern to deduct the Requirements and actual Information Elements from 
- but that all happens in the Information Model (because the manifest 
and complementary draft around it are the target there).

In the TEEP architecture, first the terminology is defined and then four 
very concise use-cases are defined, which directly leads to the system 
model. That is possible, because the application of OTrPv1 is 
well-understood and small in scope, I assume. But I am not as familiar 
to the background of TEEP as I am familiar with the background of SUIT.

So we have one case where a big number of use-cases go into the 
Information Model and one case where a small number of use-cases go into 
the architecture. Both designs are based on the background of the 
solution space of the working groups.

Only the WG can decide, if it makes sense to put a big number of use 
cases at the top of the architecture, then derive workflow compositions 
from them, and then derive the terminology from that after that.
That has not been done yet, as far I can see (and I only know SUIT and 
TEEP as the related working groups, SACM uses a different approach and 
has a separate use-case document).

Viele Grüße,

Henk

On 10.10.19 01:41, Guy Fedorkow wrote:
> Hi Henk,
> 
>      Do you think that the ‘readability’ concerns would be addressed if 
> the architecture doc were to adopt a summary of some sort of the 
> use-cases as part of its introductory material?  That would give a 
> definition of the problem to be solved written in common language, so 
> ordinary people could read it, followed by the more-carefully-defined 
> terms, roles and procedures?
> 
>      /guy
> 
> *From:* RATS <[e-mail]> *On Behalf Of * Kathleen Moriarty
> *Sent:* Wednesday, October 9, 2019 4:10 PM
> *To:* Henk Birkholz <[e-mail]>; [e-mail]
> *Subject:* Re: [Rats] Use case -> architecture document
> 
> Hello,
> 
> Henk expressed concern with my use of the word 'merge'.  By exploring 
> this new structure, I am not suggesting that we drop content.  It's a 
> restructure proposal and hopefully a way to make the document more 
> accessible.  I am not suggesting essential components be dropped, but 
> would like them described more clearly.  This may help reset the 
> readability of the document.  Obviously, the WG is who decides what gets 
> adopted as a WG item.  I'd also like to make sure the end result is 
> something that is easily adoptable by industry that are already moving 
> forward with proprietary solutions.  We should put our best foot forward 
> to try to influence and gain adoption.
> 
> Michael offered to look at the structures of the TEEP and SUIT 
> architecture documents and to see what might make sense here and will 
> post to the list.
> 
> Best regards,
> 
> Kathleen
> 
> On Wed, Oct 9, 2019 at 1:33 PM Kathleen Moriarty 
> <[e-mail] 
> <mailto:kathleen.moriarty.ietf@gmail..com>> wrote:
> 
>     Hi Henk,
> 
>     On Wed, Oct 9, 2019 at 12:37 PM Henk Birkholz
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>         Hi Kathleen,
>         hi list,
> 
>         while I of course understand your point of "the simpler, the
>         better", I
>         am still a bit of at a loss, what the actual issue is. You are
>         proposing
>         a solution to a problem that I currently have not seen being
>         described yet.
> 
>         Maybe we should do things in order and describe the problem
>         better first
>         and then see how to resolve it inside the existing document?
> 
>     I tried to provide extensive comments, but they were not considered
>     and I was asked by you to look at the new version again.  I spent
>     over 2 days trying to help, but I think to speed this work up, we
>     need to do a pivot and focus first on the architectural patterns.
> 
> 
>         That is basically the reason for my request to you on actual
>         issues in
>         my last comment. I understand the category of the problem
>         "readability"
>         and I assume analogously "comprehensibility", of course, but I
>         think
>         that is too vague to actually act on.
> 
>     I tried to help...
> 
> 
>         What you are describing with respect to workflow diagrams that
>         is using
>         the roles - Dave did already provided those and walked us
>         through them
>         for example at the first interim, and we are doing ASCII art on
>         them
>         currently.
> 
>     As a reminder, we don't need ASCII art anymore, version 3 was
>     released for publishing.  If Dave contributes his pictures, we can
>     use them.
> 
>     In terms of how roles are discussed, I think that can be improved
>     further.  Can we just wait and give Dave a chance to write up the
>     text he has said he would help with on this rather than trying to
>     all do the same thing?
> 
> 
>         In fact, that very first action item wrt what we are working on
>         (well,
>         we paralleled some other items, too) back in early September was:
> 
>          > * to elaborate on the use of RATS Principals, including more
>         exemplary diagrams of RATS Role composition and interaction
>         between RATS Principals based on the use case document (and by
>         that address a unified mapping to TEEP, RIV, and models that use
>         EAT)
> 
>         So what am I hearing now is that Dave is now starting to do the
>         exact
>         same thing, with the exception of not using the terms defined in
>         the
>         architecture. Is that correct? I am still not sure what issues
>         we are
>         trying to address here.
> 
>     Not necessarily..  His work used terms in TEEP and SUIT.  Some of
>     these terms are defined int he current architecture document.  Once
>     he has this written, then merging again makes sense so that we can
>     then get language consistent and using what's been agreed upon to
>     date. I think this will actually speed up the work and adoption.  It
>     will also lower the learning curve.  You've done really good work
>     and I would like the barrier to entry lowered.  I would really like
>     to see all of this be successful and don't think this exercise will
>     take much time, but do think it will be very worthwhile.
> 
>     I'd like to see this happen in a few steps as described in my last
>     message.
> 
>     Best regards,
> 
>     Kathleen
> 
> 
>         Viele Grüße,
> 
>         Henk
> 
>         p.s. with respect to pair programming, I really hope that solutions
>         drafts simplify that process the same way the first RATS YANG
>         module
>         does it today, already.
> 
>         On 09.10.19 18:03, Kathleen Moriarty wrote:
>          >
>          > I would rather see the architectural patterns come before the
>         specific
>          > terminology.  If you look through the slides from Dave's
>         presentation at
>          > our previous interim meeting, he laid out several
>         architectural patterns
>          > using the same language that is used in SUIT and TEEP.  It is
>         desirable,
>          > IMO, to begin with architectural patterns that can be used in
>         necessary
>          > use cases.  Additional architectural patterns may arise, but
>         we have a
>          > nice starting point.
>          >
>          > See:
>          >
>         https://datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment
>         <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qWKJ61OI$>
>          > It defines the passport, background check, and verifying
>         relying party
>          > architectural patterns for RATS.
>          > It also provides an illustration of how the OTrP model for
>         device state
>          > can fold into each of those 3 RATS architectural patterns.
>          >
>          > What Dave is planning to do is to write text describing these
>          > architectural patterns.  It will likely be in the language
>         similar to
>          > what's been used in SUIT and TEEP as his slides match the
>         terminology.
>          >
>          > Attestation has countless use cases, and several known
>         architectural
>          > patterns to date.  The document would first define these
>         patterns..
>          > Then, like SUIT, a high-level description of use cases could
>         be included
>          > with pointers to other future WG drafts that more fully
>         define the use
>          > cases.  Any additional terminology that is necessary could
>         then be
>          > added, but keeping in mind that we do not want unnecessary
>         terms.  If we
>          > start from the models, it will be easier to maintain the
>         scope and set
>          > of terms.  The terms would come from the current document,
>         but language
>          > may be adjusted as needed.
>          >
>          > The specific use case details that map claims could be in a
>         later
>          > section with the IANA section defining claims for use cases
>         to be added
>          > to the CWT and JWT registry.
>          >
>          > I work for Dell and would like to be able to bring this work
>         forward for
>          > PoCs.  However, our teams (like many others) use pair
>         programming..  This
>          > means the 2 coders work as a team and in our model, they
>         rotate to a new
>          > project every 2 weeks.  This helps with innovation and other
>         benefits.
>          > If each pairing team has a significant learning curve, a lot
>         of time
>          > will be wasted and the PoC would not make progress.
>          >
>          > If the goal for service providers and others is to use this
>         technology
>          > (as is my goal), we need to make it something that is
>         accessible to
>          > many.  The developers at many organizations will use crypto
>         libraries,
>          > but will not necessarily be security people.  They will be
>         starting from
>          > a point where they do not have security specific language nor
>         this very
>          > specific set of terms that is being defined.  The simpler we
>         can keep
>          > it, the better to gain wider adoption.
>          >
>          > I think if we step back and see what Dave does with the
>         document to
>          > define the architectural patterns, then we can decide how we
>         merge
>          > content with readability as a goal.
>          >
>          > Best regards,
>          > Kathleen
>          >
>          > On Wed, Oct 9, 2019 at 10:50 AM Schönwälder, Jürgen
>          > <[e-mail]
>         <mailto:[e-mail]>
>          > <mailto:[e-mail]
>         <mailto:[e-mail]>>> wrote:
>          >
>          >     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]>
>          >     <mailto:[e-mail]
>         <mailto:[e-mail]>>
>          >      > > <mailto:[e-mail]
>         <mailto:[e-mail]>
>          >     <mailto:[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]>
>          >     <mailto:[e-mail] <mailto:[e-mail]>>
>          >      > >     <mailto:[e-mail]
>         <mailto:[e-mail]>
>          >     <mailto:[e-mail]
>         <mailto:[e-mail]>>>] *代表 *Kathleen Moriarty
>          >      > >     *发送时间:*2019年10月8日19:25
>          >      > >     *收件人:*[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>          >     <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[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] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>          >      > > https://www.ietf.org/mailman/listinfo/rats
>         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qdJAAYPI$>
>          >      > >
>          >      >
>          >      > _______________________________________________
>          >      > RATS mailing list
>          >      > [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>          >      > https://www.ietf.org/mailman/listinfo/rats
>         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qdJAAYPI$>
>          >
>          >     --
>          >     Juergen Schoenwaelder           Jacobs University Bremen
>         gGmbH
>          >     Phone: [phone]         Campus Ring 1 | 28759
>         Bremen | Germany
>          >     Fax:   [phone]       
>           <https://www.jacobs-university.de/
>         <https://urldefense.com/v3/__https:/www.jacobs-university.de/__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qb0VL94k$>>
>          >
>          >
>          >
>          > --
>          >
>          > Best regards,
>          > Kathleen
> 
> 
>     -- 
> 
>     Best regards,
> 
>     Kathleen
> 
> 
> -- 
> 
> Best regards,
> 
> Kathleen
> 
> Juniper Business Use Only
>