[Iot-onboarding] draft-sarikaya-t2trg-sbootstrapping-05 is really good

[Michael Richardson <[e-mail]>]

B. Sarikaya, M. Sethi and D. Garcia-Carillo
have done some very good work with 
  https://datatracker.ietf.org/doc/html/draft-sarikaya-t2trg-sbootstrapping-05

The intro section deals with "bootstrapping" vs "onboarding", and there is
also the term "enrollment"... 

Section 3 does not mention BRSKI, and it probably should, but you mention it
in section 4... not sure I understand why. I guess it is a managed method?


"Opportunistic and leap-of-faith methods"

I think that this category should be split up, and distinguish between
methods that are Opportunistic (no memory, no implied trust), those which
are LoF followed by Trust on First Use.

      Additionally, various
      online services such as Gmail and Facebook allow anyone to create
      a new identity during the initial setup and later only verify the
      continuity of the same identity.

Not sure I understand this, maybe a reference would be worth it.
Since I don't understand it, I don't know if it fits.

section 4.1 lists a bunch of one-touch (1+) methods as managed,
which I actually find puzzling.  I do not consider many of the methods listed
as enrollment or onboarding methods.  (By the (a) defintion of Introduction)
They are all (b) methods, yet you include BRSKI there.

[I-D.ietf-netconf-zerotouch] is an RFC8366 based mechanism, similar to BRSKI,
but using a different set of assumptions about communications, including none
(USB key).

4.2: I'm told that Thread version n+1 uses BRSKI.

DPP:    DPP (Device Provisioning Protocol) [dpp] is a 3 message
   authentication protocol currently being standardized by the WiFi
   Alliance for devices that rely on IEEE 802.11 link-layer for
   communication.  The current DPP specification is only aimed at
   networks that use WPA2-PSK (also known as WPA2-Home) for network
   access authentication. 

I was unaware that it was limited WPA2-PSK networks. I don't think that is
true. Maybe WPA2-PSK type networks are just the sweet spot where it makes
most sense.

Generally, I really like your section 1,2.
Section 3 could use a bit of work.

I don't think the survey in section 4 is worthwhile as is.

What I'd like to see is a clear set of terminology (a la RFC7228) that we can
subsequently use.  Some really clear clarification of what some terms mean.
I don't care if due to clashes with other word uses, we "Property Red",
"RFC89AB-bootstrapping"... (or use Caribean island names or whatever).

We could stop at that point, and then let the various documents apply the
terminology to themselves.
   "According to RFC89AB terminology, BRSKI is has Property Red, and
   should be categorized into the set of Jamaican-Zero-Touch protocols"

I think that getting section 4 nailed down is not very useful in an IETF
or IRTF specification.   It will take too long, and might cause arguments
that can't be resolved, even in IETF publication time.

Instead, write a survey article for a journal (the IETF Journal is always
looking for stuff...) that applies your terminology to various protocols.  

-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-