Subject: Re: [Suit] Updated Charter Text and Way Forward

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Dec 2017 18:21:54 -0500

Waltermire, David A. (Fed) <[email-masked]> wrote:
    > Kathleen, Dave, and I met earlier today to discuss the charter and the way
    > forward. This email includes updated charter text and milestones, and a brief
    > description of the changes we have made based on the input from the mailing
    > list.

Thank you, I have no significant objections to the text, and if we went ahead
as-is, I'd consider my nitpick comments below to be in the rough.

    > In particular this group aims to publish several documents, namely:
    > * An IoT firmware update architecture that includes a description of the
    > involved entities, security threats, and assumptions.

    > * One or more manifest format specifications.

Do you want to change, "namely" to "including", such that the chairs can
decide how/if we are creating a seperate requirements document (which the
IESG is not keen on anymore), or simply having architecture and requirements
as part of another document?

    > The initial focus of this group will be development of the information model
    > for the contents of a manifest.

If this means YANG, please say so.
If it could be some other modelling language, then please say so.
If the idea is have just descriptive text, again, I'd like to know.

(I'd prefer it to use YANG.
I'm not a YANG lawyer, I feel confident I could play one on TV now, and I
believe I might volunteer to write part of a document.  The YANG->SID->CBOR
path is very close to being ready for prime time.)

    > Once there is general agreement on the
    > contents, the group will pick a small number of serialization formats such as
    > CBOR and/or ASN.1 (and their associated cryptographic mechanisms) to encode

With the caveat that ASN.1 and CBOR are in difference categories.
  ASN.1 <-> YANG     information model
  DER   <-> CBOR     serialization format

    > This group will aim to maintain a close relationship with silicon vendors and
    > OEMs that develop IoT operating systems.

As I said before, I'd like to know what this means from a concrete point of
view.  What metrics might the IESG use to decide if we are succeeding?
("Tell me how you'll measure me, and I'll tell you how I'll behave")

    > Jul 2018 Calendar item: Second interoperability event at IETF 102.
    > Mar 2018 Calendar item: First interoperability event at IETF 101.

If we can get there by then, great.   I'm doubtful.

    > Mar 2018 Adopt a manifest information model as a WG item.
    > Mar 2018 Adopt initial manifest serialization format(s) as WG item(s).
    > Jan 2018 Adopt "Architecture" document as WG item.

I don't know if the informational model or the requirements go in the architecture document.
I think that they do?

    > Regards,
    > Dave Waltermire and Dave Thaler

Thanks, I really like the new text.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dave Thaler <[email-masked]>
Date: Mon, 4 Dec 2017 23:41:53 +0000

> If the idea is have just descriptive text, again, I'd like to know.

I believe our (the chairs') intent was just to generically say that even if there's different serialization 
formats, there is just one common conceptual information model so that the same tool/UI/service/whatever
could be used with devices that use different serialization formats, which is how we read the BoF/list consensus. 
Whether that is in a YANG data model or something else is left to the WG to decide, as opposed
to being constrained by charter.  That's because we want to charter while that discussion is still 
ongoing, rather than wait.

Dave Thaler

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 5 Dec 2017 10:03:58 -0500

Hi,

Just responding on the one point of IESG preferences as the BoF chairs
are managing the rest.

On Mon, Dec 4, 2017 at 6:21 PM, Michael Richardson
<[email-masked]> wrote:
> ("Tell me how you'll measure me, and I'll tell you how I'll behave

Liaisons should be sent when appropriate to inform related groups of
progress or with potential issues to discuss.  If issues bubble up to
the IESG needing more than a WG chair liaison statement, then the IESG
will be concerned.

> I don't know if the informational model or the requirements go in the architecture document.

This depends on how you scope the architecture document.  Some really
nice ones have come through the IESG recently that were very well
received.  The ones that seemed the most useful (at least to the IESG)
were architecture documents that connected the various WG documents
and documents outside of the WG and came late in the WG process.  They
are helpful documents that will live on and be useful to someone
wanting to piece together the architecture for the protocol(s) with
explicit pointers to documents.  The requirements could be in such a
draft and then the requirements could change as needed when the work
evolves as opposed to a set of requirements that holds the WG to early
requirements.

I'd keep the information model separate, but that's me as an
individual, not AD.  The AD is here to support WG decisions and offer
guidance.

> Thanks, I really like the new text.

Excellent.  Nice work, everyone!

Thank you,
Kathleen
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Dec 2017 14:34:21 -0500

> the IESG needing more than a WG chair liaison statement, then the IESG

The Liason process has always seemed very formal; I suspect that this is
because we mostly liason with other entities (so-called SDOs) that do not
really recognize individuals.

I think that the liason system is not a good way to keep in touch with
silicon vendors and OEMs.  I am taking this to mean that we need to reach
into the places that they communicate and talk.   Ones that are relatively
close (due to shared people) might include Fairhair, Thread, OCF, OIC, and
IOTSF.   I'm sure that ARM has some kind of conference or meeting that Hannes
can tell us about.... I'd like to see us deputize someone (maybe Hannes) to
socialize things there.

Kathleen, so you told us about metrics that if non-zero would alarm the IESG.
(Things that WG chairs could not deal with).
But what metrics would the IESG use to know if we were doing a good job here?

    > and documents outside of the WG and came late in the WG process.

I also like such documents.
Can you point to specific examples here?

I think that they should be started now, be maintained as we go, and should
get published last.   The work on it should be specifically iterative, and
not waterfall in nature.

    > They

+1

    > individual, not AD.  The AD is here to support WG decisions and offer

I think that this is reasonable, but is not reflected in the milestones.
Should I suggest some radical changes to the milestones, or shall I wait for
chartering?

I think we are not on the agenda for the telechat on the 14th anymore?

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 5 Dec 2017 15:18:30 -0500

Hi Michael,

> can tell us about.... I'd like to see us deputize someone (maybe Hannes) to

Good point, thank you.  I was mainly thinking about the BoF discussion
on GP in this response.

> But what metrics would the IESG use to know if we were doing a good job here?

Meeting milestones and staying within the charter (or altered charter)
of work is the first metric. The IESG is also concerns with working
groups that spin there wheels in bike shed arguments for too long.
So, if the WG gets hung up on format prioritization or something
similar, this will raise a concern.  If the WG makes decisions, they
should not be revisited at a high frequency, but rather clearly
documented for reference so the WG can continue based on that
agreement.  I have spoken to the BoF chairs about this already and
have some strategies to assist with this goal of being productive.

Producing useful and implemented specs is also a measure of success -
probably the most important one.  I'm partial to having them
documented in CodeStand.ietf.org as it will be integrated with the
tracker soon and you'll be able to see how many implementations there
are for any draft or RFC if used consistently.

> Can you point to specific examples here?

Sure, and I meant to do that.  The RTCweb one was received extremely well.
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/>

> get published last.   The work on it should be specifically iterative, and

Agreed.

> Should I suggest some radical changes to the milestones, or shall I wait for

Suggest away, it would be good to get agreement on these and see what
the BoF chairs and list participants have to say.

> I think we are not on the agenda for the telechat on the 14th anymore?

As of right now, it is still reasonable per the timeline Dave posted.
If there is agreement, why hold things up?  I'll post the updated text
to the datatracker in the next day or so and make edits as needed.  We
could then send out the charter to the announce lists for external
reviewers as well, giving them another week to review and comment.

I don't think any of the charter changes were radical.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 8 Dec 2017 15:07:00 -0500

The updated charter text is now posted as version 9 on the datatracker
for review:

https://datatracker.ietf.org/doc/charter-ietf-suit/

The milestones will be updated in the next few minutes.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Dec 2017 19:06:13 -0500

> https://datatracker.ietf.org/doc/charter-ietf-suit/

Looks good.
Still some wrapping problems with the point form, but meh.
I think that I missed the message in between, but that's okay.

    >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/>

Thanks!

    >> I don't think any of the charter changes were radical.

okay!

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [