Re: Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,
At 11:18 27-08-2014, IAB Chair wrote:
This is a call for review of "Architectural Considerations in Smart Object Networking" prior to potential approval as an IAB stream RFC.

It's good to see the IAB working on a document about architecture.

In Section 2.1:

  "Which IP version(s) should be used?"

That's a good question to ask. I gather that the answer will be IPv6 as it does not make sense to use IPv4.

Section 2.2 mentions a "cloud-based infrastructure".  What is that?

  "Often the application service provider (example.com in our
   illustration) also sells smart objects as well.  In that
   case the entire communication happens internally to the
   provider and no need for interoperability arises."

That sounds like an ideal scenario for vendor lock-in. The following paragraph explains that it leads to "silos". It is then mentioned that "To prevent silos, example.com may allow third party device vendors to connect to their server infrastructure as well". It is not in the interest of example.com to prevent silos.

What does "developing consensus-based standards" (Section 3) have to do with reuse of Internet Protocols?

Section 5 discusses about "design for change". The tussle does not work when there is are imbalances in the weight given to input from the different players. The section mentions design. In my opinion it would be worthwhile to look at the assumptions as it influences the designs and the choices. I could not find any discussion about assumptions in the document.

Section 6 is about Security Considerations and it quotes the IETF as an example. Given the IETF track record about not being able to predict an attack [1] I would look at the IETF work style as a theoretical example.

From Section 7:

  "Robust cryptographic techniques and  proper authentication
   frameworks have to be used to limit the risk of unintended
   data transfers or unauthorized access."

How does cryptographic techniques and authentication frameworks help in limiting the risk of unintended data transfers and unauthorized access? There was a breach in 2012 and the valued [sic] customers were informed about it ( http://www.rge.com/letter.html ). I didn't look into this further as I am not sure whether there would be adequate public information available for other countries.

The guideline about "data quality" sounds more like minimizing the collection of data. Please note that there are problems even with anonymized data (re. dataset released in New York City).

As I reached the end of the document I pondered on the guidance the document provided. The only guidance I can think of is design for change, security and privacy. I gather that it is the best the IAB can do.

Regards,
S. Moonesamy

1. I am using a term that gained IETF Consensus.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]