[Rats] Draft minutes from the 01/16/2019 meeting

[Roman Danyliw <[e-mail]>]

Hello RATS!

Draft minutes from the 01/16/2019 virtual meeting can be found below.  If you have any revisions, please send it to the chairs.

Regards,
Roman and Nancy

--[ snip ]--
RATS Virtual Meeting Notes
January 16, 2019

BLUF
====
** There was consensus on charter text that:
   -- includes work items #1 - 4
   -- removes work item #5 (and related references in the Goal and Introduction)
   -- remove references to roots of trust

** The co-chairs have the actions to:
   -- publish the agreed upon charter text from this meeting
   -- solicit feedback from the mailing list on this charter language 
   -- ensure there is a RATS meeting as another BoF or WG at IETF 104

Attendees
=========
** Nancy Cam-Winget (co-chair)
** Roman Danyliw (co-chair)
** Ben Kaduk (responsible AD)
** Henk Birkholz
** Carsten Bormann
** Ira McDonald
** Michael Richardson
** Giri Mandyam
** Daniel Smith
** Ned Smith
** Hannes Tschofenig
** Eric Voit
** Carl Wallace

Agenda Item #1: Chairs' view of status
======================================
Slides: https://mailarchive.ietf.org/arch/msg/rats/-rq_gQq2LNTeofG55xH_wPSB1_I/3

The co-chairs summarize the outcomes from the IETF 103 BOF and from discussions on the mailing list.  It appeared to the chairs that there was consensus around charter work items #1 - 4 from the mailing list, but not work item #5.  These observations facilitated a conversation about the scope of the work.

o Per slide #5 (diversity of viewpoints):

Q: (Roman Danyliw) Did we miss other scopes per the group discussions?
A: (Henk Birkholz) Not questioning the summary, but surprised that protocol position of scope 1

Q: (Ned Smith) Is Scope #3 is hybrid, what is the origin?
A: (Nancy Cam-Winget) It is based on chair's understanding from mail list discussion

Discussion summary: agreement by attendees that Scope #1 - 3 correctly represents the voiced opinions

o Per slide #6 (areas of consensus):

Q: (Giri Mandyam) Can you clarify what you mean by protocol [per work items #4] -- like HTTP?
A: (Nancy Cam-Winget)
A: (Giri Mandyam) If there was a new HTTP header would RATS do it?
A: (Nancy Cam-Winget): Maybe, as RATS might define it but we would need to work with other WGs
A: (Ben Kaduk) It would be on a case by case basis
A: (Roman Danyliw) We're getting ahead of ourselves. This gets to Scope #3.  Nevertheless, even if we don't invent new protocols we'll have to describe how to reuse prior work.  This will have to be captured in a draft text.
A: (Henk Birkholz) Yes, we would not reinvent a redundant protocol

Q: (Roman Danyliw) Is there any disagreement that work items #1-3 needs to be included.
[No disagreement voiced] Consensus

Q: (Roman Danyliw) Is there any disagreement about the need for a protocol to convey the claims (work item #4) whether new or reused?
[No disagreement voiced] Consensus

Q: (Roman Danyliw) There was significant discussion on the list about the necessity of a Root of Trust (RoT).  Does this language need to be in the charter?  Does it affect the work items?
A: (Hannes Tschofenig) RoTs may impact the architecture and use cases, but doesn't need to be talked about in item 2-3.
A: (Nancy Cam-Winget) To clarify, does resolution on the need for a RoT a necessity for the charter text?
A: (Hannes Tschofenig) No.  The charter doesn't need to discuss it.  It is already quite long.
A: (Ben Kaduk) As AD, it is reasonable to charter first and then debate terminology and architecture as to whether it needs to be included in the charter
A: (Henk Birkholz): [Agrees with Ben and Hannes] [Agrees with Hannes that charter text is long]
A: (Dan Smith) I brought up the RoT discussion, but agree that it doesn't belong in the charter
A: (Ned Smith): I also believe that the RoT is an as important component, but not something charter needs to state

Q: (Roman Danyliw) The consensus appears to be that the charter does not need to reference a root a trust.  Does anyone disagree?
[No disagreement voiced]

Comment: (Roman Danyliw) Per the last column of this slide, the chairs do not believe there is consensus around work item #5.
A: (Ned Smith) Is there a proposal on the table?
A: (?) No
A: (Ned Smith) What's the risk if #5 is left out
A: (Hannes Tschofenig) If left in, it could cause confusion, and could risk of failure (unable to get a charter approved)
A: (Ned Smith) Can we recharter if we decide we need #5?
A: (Ben Kaduk) Yes, it is typical to recharter. If there are items that could be construed as a distraction initially, then it could slow or stop chartering initially.
A: (Roman Danyliw): It is exceedingly rare to see a WG that doesn't eventually recharter.

o Per slide #7 (possible next steps):

Comment: (Henk Birkholz): To highlight how the work splits, there's a common denominator "remote attestation".  The semantics at a fundamental level are somehow the same.  So if there are two WGs [per possible next step #4], then they would have to be very tightly aligned. Practically, two WGs would create a lot of overlap.
A: (Ben Kaduk) To rephrase, IETF does not want to generate competing standards.
A: (Hannes Tschofenig) Phrased differently, IPSec and TLS both provide comms solution but different use cases.  They are very similar (before TLS 1.3 came).  We have to make sure that the use cases are similar enough as we can't just clump everything together.  Just because it has attestation as name, doesn't mean they are the same. 
A: (Henk Birkholz) They are the same semantics perhaps with different constraints
A: (Hannes Tschofenig) It is concerning that it is taking so much time to agree on something and slowing progress. If you compare EAT and other documents (like router environments), they look very different.  We should harmonize, but it may diverge in the end.
A: (Roman Danyliw) In the interest of focusing the discussion on the crisping language for charter, is this discussion similar to the one about RoT -- important for a WG to consider, but not for the charter language?
A: (Eric Voit) If there are two WGs, there will be problems with same members trying to span both.  If there is terminology base, they should be done together. It would be difficult to integrate if there are two WGs
A: (Nancy Cam-Winget): [clarifies the question]
A: (Hannes Tschofenig): We're making the assumption that other use cases are similar enough that charter covers all of them.  It is a guess, hopefully it is correct but if people think it is useful to combine it, we can try it out. They're working on trusted FW code in the next few weeks, so can look at what that is like and if it makes sense for other use cases
A: (Henk Birkholz): We've made efforts in the last 24hrs to define a proposal with common ground.  It could result in 2 different drafts for how attestation serves the use cases.

Q: (Roman Danyliw) To summarize, there appears to be an abundance of caution noted about splitting the work across multiple WG groups [as suggested by slide #7, possible next step #4].  There is also the caveat that we're discussing the topic in the abstract. All feedback appears to be one WG is the preferred options [per slide #7, possible next steps #1 - 3].  Any disagreement?
[No disagreement voiced]

The chairs reviewed the work items proposed in the charter.

Q: (Roman Danyliw) The chairs are hearing consensus around Scope #3 (i.e., work items #1 - 4).  Do the attendees concur we should move on to polishing the charter text around Scope #3?
A: (Henk Birkholz) Agree with Scope #3
A: (Ned Smith) Agreed.
A: (Carsten Bormann) I agree as we can address #5 later.  We will eventually have to work on this.
A: (Ira McDonald) Agrees (knowing that #5 can be addressed later)
A: (??) I don't understand #5.


Agenda Item #2: Charter Text
============================
Initial Text: https://mailarchive.ietf.org/arch/msg/rats/-rq_gQq2LNTeofG55xH_wPSB1_I/2
Revised Text: https://mailarchive.ietf.org/arch/msg/rats/MQLZIkIK23ZlSBMB5wJjo71bOr0

The chairs displayed the draft charter language and made updates in real-time based on the discussion.

Per Program of Work, Item #5
----------------------------
Comment: (Henk Birkholz) [Describes the appraisal of attestation evidence per #5]
A: (Ned Smith) It will be difficult to do use cases and architecture where there's no mention of conveyance of measurement
A: (Ben Kaduk) Add text "the way relying party uses the information may include values but the procedures for how that's achieved is out of scope"
A: (Dan Smith) As long as there's a model to convey RoT and allow RP to appraise it is sufficient.
A: (Henk Birkholz) Conveyance could also mean conveyance of results and claims
A: (Carl Wallace) There's a lot of variance to what a verifier would do.
A: (Henk Birkholz) How do you define how the rule works?
A: (Ben Kaduk) There's two layers: verifying signatures, tags (we need to say how that's done), but then what to do with it (compare on reference values, range) that's the question that we're trying to put out of scope.
A: (Ned Smith) There's an expectation that we compare with reference values
A: (Henk Birkholz): we need to agree what we are conveying on initial set and then we can add to that

[charter text: 
-- added text on what is out of scope in the Goals Section
-- removed "Based on the provided evidence" phrase in the introduction
-- removed work item #5 from the Program of Work]

Per the discussion on removing RoT
----------------------------------
[charter text: removed reference in Program of Work introductory text]

Per the related work in the Introduction/Goals
----------------------------------------------
Q: Do any more projects need to be referenced in the Introduction?  Do any more IETF WG need to be referenced in the Goals?
[after discussion] No

Next Steps
==========
Q: (Nancy Cam-Winget to AD) Could we submit a charter to the IESG without another BoF?
A: (Ben Kaduk) Yes.  Show consensus on the mailing list for the charter text.  Also show interest from people to work in the WG.  With those items, the charter can progress for WG consideration.

--[ snip ]--