Subject: [Rats] Where Do Interaction Models Go?

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 Jul 2020 15:07:40 +0200

Hi list,

our first virtual session on July 28th is approaching. At the last 
meeting, we highlighted the question: where do interaction models go?

Context: there are three quite common interaction models (plus minimal 
requirements and information elements for them) that can be used to 
convey RATS Conceptual Messages, such as Evidence or Attestation 
Results. Most Conceptual Messages should include only up-to-date content 
(commonly referred to as "fresh") to be feasible. As a result, 
interaction models directly support methods to show that content is 
fresh (challenge-response & streamed remote attestation) or don't have 
to because the content shows that by itself (time-based remote attestation).

Problem: Reiterating how the common models work and how they are related 
in every solution draft can prove to be error prone, ambiguous, 
difficult to compare in English, or simply be redundant.

Solution: Describing them once and then referencing the bulk of it 
eliminates the need for text cloning, danger of inconsistencies/subtle 
deviations, and redundancy in general.

The remaining question is: where should this content about interaction 
model go?

At the last meeting four options were presented:

* Option 1: standalone (one I-D for each model)
* Option 2: standalone (one I-D for all models)
* Option 3: all three models merged into the architecture I-D
* Option 4: each model merged into a separate solution I-D

Each option has pros and cons. So, I'd like to bring this question to 
the list (,finally... I can be quite slow).

There is of course the current reference interaction model I-D that 
talks about the three models and how direct anonymous attestation can be 
enabled by all three of them. Please have a quick look, maybe that helps 
to provide some feedback here :) Five drafts reference this one at the 
moment:

> https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/

We will dedicate some time to this topic on Tuesday and hope for some 
feedback!

Viele Grüße,

Henk

---

From: Ira McDonald <[email-masked]>
Date: Thu, 23 Jul 2020 11:48:06 -0400

Hi,

I strongly favor option 2 (one I-D for all models).

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted
Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Thu, Jul 23, 2020 at 9:08 AM Henk Birkholz <
[email-masked]> wrote:

> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Monty Wiseman <[email-masked]>
Date: Thu, 23 Jul 2020 21:11:09 -0400

I prefer Option 2 (one I-D for all models). This supports more 
consistent models

and is simpler to reference by other standards (which is the overall 
objective).

Monty Wiseman

On 7/23/20 11:48 AM, Ira McDonald wrote:
> /Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG/
> /Co-Chair - TCG Metadata Access Protocol SG
> /
> /Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: [email-masked] <mailto:[email-masked]>
> (permanent) PO Box 221  Grand Marais, MI 49839 906-494-2434/
>
>
> On Thu, Jul 23, 2020 at 9:08 AM Henk Birkholz 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi list,
>
>     to because the content shows that by itself (time-based remote
>     attestation)..
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Panwei (William)" <[email-masked]>
Date: Fri, 24 Jul 2020 01:21:21 +0000

Hi,

I prefer option 2.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: RATS [mailto:[email-masked]] On Behalf Of Henk Birkholz
> Sent: Thursday, July 23, 2020 9:08 PM
> To: [email-masked]
> Subject: [Rats] Where Do Interaction Models Go?
> 
> Hi list,
> 
> our first virtual session on July 28th is approaching. At the last meeting, we
> highlighted the question: where do interaction models go?
> 
> convey RATS Conceptual Messages, such as Evidence or Attestation Results.
> Most Conceptual Messages should include only up-to-date content
> (commonly referred to as "fresh") to be feasible. As a result, interaction
> models directly support methods to show that content is fresh
> (challenge-response & streamed remote attestation) or don't have to
> because the content shows that by itself (time-based remote attestation).
> 
> Problem: Reiterating how the common models work and how they are
> related in every solution draft can prove to be error prone, ambiguous,

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 24 Jul 2020 16:38:02 +0000

2 makes good sense.  This allows a common structure which can show the commonality between specific I-Ds.   It also doesn't overburden/slow closure on the architecture doc.

Eric

> models directly support methods to show that content is fresh (challenge-
> response & streamed remote attestation) or don't have to because the
> content shows that by itself (time-based remote attestation).
> 
> Solution: Describing them once and then referencing the bulk of it eliminates
> the need for text cloning, danger of inconsistencies/subtle deviations, and
> redundancy in general.
> 
>

---

From: Guy Fedorkow <[email-masked]>
Date: Mon, 27 Jul 2020 17:27:53 +0000

Hi Henk,
  I'm fine with Option 2 -- separate draft that doesn't impede closure of the Architecture draft.
/guy

Juniper Business Use Only

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Thursday, July 23, 2020 9:08 AM
To: [email-masked]
Subject: [Rats] Where Do Interaction Models Go?

[External Email. Be cautious of content]

Hi list,

our first virtual session on July 28th is approaching. At the last meeting, we highlighted the question: where do interaction models go?

Context: there are three quite common interaction models (plus minimal requirements and information elements for them) that can be used to convey RATS Conceptual Messages, such as Evidence or Attestation Results. Most Conceptual Messages should include only up-to-date content (commonly referred to as "fresh") to be feasible. As a result, interaction models directly support methods to show that content is fresh (challenge-response & streamed remote attestation) or don't have to because the content shows that by itself (time-based remote attestation).

Problem: Reiterating how the common models work and how they are related in every solution draft can prove to be error prone, ambiguous, difficult to compare in English, or simply be redundant.

Solution: Describing them once and then referencing the bulk of it eliminates the need for text cloning, danger of inconsistencies/subtle deviations, and redundancy in general.

The remaining question is: where should this content about interaction model go?

Each option has pros and cons. So, I'd like to bring this question to the list (,finally... I can be quite slow).

There is of course the current reference interaction model I-D that talks about the three models and how direct anonymous attestation can be enabled by all three of them. Please have a quick look, maybe that helps to provide some feedback here :) Five drafts reference this one at the
moment:

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bir
> kholz-rats-reference-interaction-model/__;!!NEt6yMaO-gk!SYqBRt5nXIi2cw
> gezjeQbps4FpiEHZvAX2DbPXFG2ODk1Ck9LDvFE-AvEHZwiEJWJEs$

We will dedicate some time to this topic on Tuesday and hope for some feedback!

Viele Grüße,

Henk

_______________________________________________
RATS mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rats__;!!NEt6yMaO-gk!SYqBRt5nXIi2cwgezjeQbps4FpiEHZvAX2DbPXFG2ODk1Ck9LDvFE-AvEHZwtdYEfZk$

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 27 Jul 2020 18:32:59 +0000

Hi Henk,

On 23/07/2020, 14:08, "Henk Birkholz" <[email-masked]>
wrote:
> Results. Most Conceptual Messages should include only up-to-date
> content (commonly referred to as "fresh") to be feasible. As a result,
> attestation).
> related in every solution draft can prove to be error prone,
> ambiguous, difficult to compare in English, or simply be redundant.
>
> talks about the three models and how direct anonymous attestation can
> be enabled by all three of them. Please have a quick look, maybe that
> helps to provide some feedback here :) Five drafts reference this one
> at the moment:
>

Highlighting common interaction patterns that can be grasped without
delving into protocol details seems like a useful undertaking.  For
that reason I'd prefer we don't do 4.

Interaction models looks orthogonal to the architecture, so I wouldn't
conflate the two - risking slowing down delivery of the arch doc, as
already noted by Guy and Eric.  This rules out 3.

Which leaves me with either 1 or 2.  However, if I have to choose, I
wouldn't do 1 since it's not clear to me what the advantage of having
multiple separate docs is.  (I seem to only see disadvantages: editorial
and process overhead, scattered reading.)

Therefore, I'd say 2.

Cheers!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.