Hi Elliot, all,

Fine with most of the points, especially if there are changes for CHIP or ETSI to dig on those issues.

Regarding the numbering, I fully understand that the final page numbering depends on the RIPE publication … however, because the “draft” document has an index/ToC, it should not be too much difficult, to improve readability when you forward the new version, to include pages numbers already. It helps to be able to follow the index and also to be able to refer to specific issues, etc.

Hi all,

Here are the proposed resolutions to the comments raised:

Hi all,

 

I’m not sure if this should be considered in this document or other future ones, or other foras.

 

1.       Should IoT devices be allowed to send information to the cloud “always” or the user must have the choice to disable that? I’ve seen many devices, even CPEs, using OpenWRT or a derivative firmware, sending stuff to the manufacturer, “hijacking DNS”, etc. This may be even a regulatory issue.

As Michael alluded, this might be suitable for a different document, but ours is more focused on guidance for ISPs and firewall manufacturers, and less so toward IoT device manufacturers, particularly when it comes to regulatory compliance matters.

2.        

 

3.       Should IoT devices have a standard API to be managed? Otherwise, consumers are unprotected and they may need to throw to the trash can hundreds of euros in case of a manufacturer Cloud failure, vendor bankruptcy, vendor failure to provide security updates, etc., etc.

While the authors agree that this is an important issue, it seems like one to be taken up in a different document for the reasons discussed above.  This may be a better topic for ETSI.  I will also note that there is the possibility that the Connected Home IP Alliance (CHIP) will be going right there very soon.

 

In my opinion both are related to device security in the Home. I’m also not saying is in the scope of this WG, as said, it may come to IETF, other standardizations foras, even regulation. It is like when we regulate if a device complies with FCC, CE mark, UL, etc., etc., but in terms of security or consumer protection.

Agree, but see above.

 

One last point. I think it will be very useful to have page numbers in this (and every) document … also in other BCOP documents, we added an annex with terminology.

Page numbering depends on the publication format, and that is up to RIPE NCC, not the authors.  We do explain the terminology as we go, and this is not a lengthy document that risks bloating a bit.  Unless people insist, we would rather not.

Toma asked for some slight modifications to the text relating to there being only two L4 protocols.  We propose the following changes:

"Comparing internet layer and layer four information to known deny-lists ("blocklists")"

and

"Validating that the internet layer and layer four information matches an associated MUD profile"

Martin asked for a reference to ntopng.  We have added a footnote that points to ntop.org.

We'll send an updated version shortly, assuming nobody objects to these resolutions.

For the authors,

Eliot

_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg