Subject: [T2TRG] T2TRG last call for draft-irtf-t2trg-iot-seccons-07

From: Ari Keränen <[email-masked]>
Date: Mon, 2 Oct 2017 07:42:15 +0000

This is the RG last call for the draft "State-of-the-Art and Challenges
for the Internet of Things Security":
https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons-07

This is the first RG last call in T2TRG.  Note that an RG last call is
not a WGLC.  RFC 5743 says about the role of the RG in the publishing
process:

   o  The Research Group (RG) performs a thorough technical and
      editorial review of the document and agrees it should be
      published.

Fundamentally, the RG needs to agree that the document should be
published.  That can be the case even if not all RG members *agree*
with the document.  RFC 5743 further says:

   o  There must be a paragraph near the beginning (for example, in the
      introduction) describing the level of support for publication.
      Example text might read: "this document represents the consensus
      of the FOOBAR RG" or "the views in this document were considered
      controversial by the FOOBAR RG but the RG reached a consensus that
      the document should still be published".

>From the discussion so far, we could agree that we have reached RG
consensus, but it is essential that we get good reviews at the present
stage of the document.  So if you have read the document and agree
with the positions taken, please say so.  If you think that there is
space for dissenting opinions, but do agree that this document should
be published, please say so.  (And, if you think it should not be
published as an RG document, please do say so, too.)

Please send your feedback to the RG list (or exceptionally to the
chairs, in Cc) by October 16th.

Thanks,
Ari & Carsten

---

From: Eliot Lear <[email-masked]>
Date: Mon, 2 Oct 2017 12:00:12 +0200

Hi,

I've read this version and support its publication.  I note that many of
the comments in my previous review have been addressed.  I believe there
are three remaining issues:

Because a substantial time is spent on bootstrapping (and rightly so) it
seems that at the very least, draft-ietf-anima-bootstrapping-keyinfra
and draft-ietf-anima-voucher should be informationally referenced.  In
fact it would be excellent if an analysis of those documents was done
against this draft as a good test as to whether we are in the right
ballpark.

Second, and this is more a point of discussion: secure communication of
device parameters may be worthy of discussion in this group, if not in
the draft itself (I think more the former than the latter, but others
might disagree).

Finally, while no easier for anyone else, many devices need to be
deployed without the expectation of DNS.  That leads to a number of
problems relating to RFCs 7252 and 7925 and certificate handling that
are probably worth their own document, but at least worth that much of a
mention.

Nit:

Section 5.11

> For instance, Dyn, a mayor DNS,

s/mayor DNS/major DNS provider/

Eliot

On 10/2/17 9:42 AM, Ari Keränen wrote:
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg
>

---

From: Mohit Sethi <[email-masked]>
Date: Wed, 11 Oct 2017 17:53:42 +0300

Hi Elliot,

Thanks for your detailed review and catching the nit in section 5.11. We 
will fix that.

Regarding your comment on bootstrapping (and secure communication of 
device parameters). I wonder what makes you think that substantial time 
(and space) in the draft is spent on bootstrapping. There is hardly a 
couple of sentences that describe bootstrapping being one of the phases 
in the lifecycle of thing in section 2.1 and section 2.2.

During the early days of the research group (while it was being formed), 
the working group had agreed that bootstrapping solutions are an 
important topic and they are better dealt with in a separate document. 
Here are slides from IETF 96: 
https://github.com/t2trg/2016-ietf96/blob/master/slides/52_seccons_v02.pdf 
where the authors had presented the way forward for the document. The 
research group had voiced agreement to move the bootstrapping solutions 
to a separate document.

I have already pointed you to the other research group draft on IoT 
bootstrapping: 
https://tools.ietf.org/html/draft-sarikaya-t2trg-sbootstrapping-03. I am 
happy to see your (anima) contributions there.

The authors are *strongly* against promoting any one technology 
(bootstrapping solution) in this document.

--Mohit

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Oct 2017 17:56:47 +0200

Hi Mohit,

On 10/11/17 4:53 PM, Mohit Sethi wrote:
> Hi Elliot,
>
> Thanks for your detailed review and catching the nit in section 5.11.
> We will fix that.
>
> device parameters). I wonder what makes you think that substantial
> time (and space) in the draft is spent on bootstrapping. There is
> hardly a couple of sentences that describe bootstrapping being one of
> the phases in the lifecycle of thing in section 2.1 and section 2.2.

I think it's a good bit of text, and with good reason.  It's a bit of a
challenge.
>
> During the early days of the research group (while it was being
> formed), the working group had agreed that bootstrapping solutions are
> an important topic and they are better dealt with in a separate
> document. Here are slides from IETF 96:
> research group had voiced agreement to move the bootstrapping
> solutions to a separate 

> https://tools.ietf.org/html/draft-sarikaya-t2trg-sbootstrapping-03. I
> am happy to see your (anima) contributions there.
>

If there are quite so many of them, then I would be fine with a separate
document.  I note that the draft is expired.  What are author intentions?

Eliot

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Oct 2017 15:16:13 -0500

> document.  I note that the draft is expired.  What are author intentions?
Hi Eliot,

I am one of the authors.
Yes we will make a revision hopefully before draft submission deadline.

Regards,
Behcet

Eliot