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

Abdussalam Baryun <abdussalambaryun@gmail.com> Thu, 28 August 2014 23:31 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: smartobjectdir@ietfa.amsl.com
Delivered-To: smartobjectdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962A81A0141 for <smartobjectdir@ietfa.amsl.com>; Thu, 28 Aug 2014 16:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM0Y4BgBJPIg for <smartobjectdir@ietfa.amsl.com>; Thu, 28 Aug 2014 16:31:05 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132261A013B for <smartobjectdir@ietf.org>; Thu, 28 Aug 2014 16:31:05 -0700 (PDT)
Received: by mail-yk0-f175.google.com with SMTP id 131so953657ykp.20 for <smartobjectdir@ietf.org>; Thu, 28 Aug 2014 16:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q7dTSbWsYXxlu2UuYQeC3sXQKP7n6Gyqbi1NcnTxII8=; b=w0hgjzuVlUM/hgmN2ZBtZ9mUROdO9OPqL65GUtBmH3NJZvZAcPOA5hHdeienMhxNT6 E0umgxZ2w10mzz1a85sQdx/LjwPhXGWbJDLSI/lFPShLaZcsNoc/GqNHAz3C3wfqyJgV /kebLA/J+xjNzygCW+Lehw5Sqc+UDHRgiA3Gra9q9nVakdMtp4GS1HsJncauHhy6sz2L zVdQwUOJbeP0ZReSvzuq3T5fWniMBsgBLb4QLTFQ8cJuFnJ3HuUdQr6Omdij9VJWNMxc Y9WWwD2xX/HwgM0u4MitVD1nOs48byFGxYmjFJMNfdpL2S6dj0CsOSgHvnLXd5jjBG4L NxfQ==
MIME-Version: 1.0
X-Received: by 10.236.135.212 with SMTP id u60mr9767966yhi.118.1409268664273; Thu, 28 Aug 2014 16:31:04 -0700 (PDT)
Received: by 10.170.44.216 with HTTP; Thu, 28 Aug 2014 16:31:04 -0700 (PDT)
In-Reply-To: <D023AA88.2CB9A%wesley.george@twcable.com>
References: <D1D25EE7-9B6F-47BD-9D39-3EC8B9288D98@iab.org> <D023AA88.2CB9A%wesley.george@twcable.com>
Date: Fri, 29 Aug 2014 01:31:04 +0200
Message-ID: <CADnDZ88dUbrJJ3-jg4nLVzYaPzXcD+HiZxzV5OG53=ncKuicCA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: "George, Wes" <wesley.george@twcable.com>
Content-Type: multipart/alternative; boundary="20cf301af8672094cb0501b8eecc"
Archived-At: http://mailarchive.ietf.org/arch/msg/smartobjectdir/zFDZOdC6i0s8bux3mOMosQhV47s
X-Mailman-Approved-At: Fri, 29 Aug 2014 08:04:49 -0700
Cc: IAB Chair <iab-chair@iab.org>, IETF SmartObjectDir <smartobjectdir@ietf.org>, IAB <iab@iab.org>
Subject: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking"
X-BeenThere: smartobjectdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <smartobjectdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smartobjectdir>, <mailto:smartobjectdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartobjectdir/>
List-Post: <mailto:smartobjectdir@ietf.org>
List-Help: <mailto:smartobjectdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartobjectdir>, <mailto:smartobjectdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 23:31:08 -0000

I agree with George which shows one important point missing, while
IMHO there may be more missing important points. However, I just read the
title and abstract and I see that this document is not specifying its
objectives, just it is general information. I don't see clear points of the
importance of this document while considering IParchitecture. I don't think
its structure fulfilling its title's aim.

------ OLD Title -----

Architectural Considerations in Smart Object Networking.


------ NEW Title -----

Architectural Design Considerations for networking Smart Objects
within the Internet of Things.


------ OLD Abstract -----

  Following the theme "Everything that can be connected will be
connected", engineers and researchers designing smart object networks
need to decide how to achieve this in practice.

This document offers guidance to engineers designing Internet
connected smart objects.


  ------ NEW Abstract ----

Following the theme "Everything that can be connected will be
connected", engineers
and researchers designing smart object networks need to decide how to
achieve this in practice. That can be done by considering architectural
issues and design guidance.

This document offers recommendations of designing Internet connected
smart objects.


Best Regards,


AB

On Wednesday, August 27, 2014, George, Wes wrote:

> I made the following comment (in part) on -03. I'm making it again,
> because it still applies to -04.
>
> "It seems odd to me that this document is silent on the architectural
> considerations that IPv4 exhaustion may have on Smart Object networking.
> RFC 6272 discusses support for both protocols, but partially because it
> was written in 2011, it treats them equally (no recommendation to support
> one protocol over another). I think we’re doing smart object implementers
> a disservice by not discussing the increasing likelihood that access to
> IPv4 addresses will be challenging and costly, especially for something at
> the scale of Smart Object networking."
>
>
> At the time, the feedback from Hannes was that discussing a specific
> protocol was too low-level for this document, but I argued that the lack
> of IPv4 address availability, the potential order of magnitude of the
> deployment of devices in applications like this, and their limitations
> (power, etc) make IPv4 vs IPv6 very much an interoperability consideration
> and an architectural consideration. If your architecture doesn't take into
> account the fact that we're out of IPv4 addresses, then it's not much of
> an architecture. Adding a discussion about IPv4's limitations and a
> recommendation for IPv6 isn't a discussion of a protocol for the sake of
> compare and contrast, as much as it is acknowledging the reality of the
> situation.
> I don't believe that smart object networking is viable at any real scale
> without IPv6. There simply aren't enough addresses, even taking into
> account RFC1918. I see this *today* in my own network with deployments
> like large-scale WiFi and cell tower deployment, set-top-boxes, etc. I
> think that's the right sort of scale to observe as an analog for smart
> object networks -- they could potentially be orders of magnitude bigger.
> The more clearly we say that smart object networks and their supporting
> systems should assume IPv6, and possibly IPv6-only because of IPv4's
> inherent scaling limitation, the better off we're going to be.
>
> So in terms of smart objects, especially those that are severely resource
> constrained, I think the recommendations are- First support IPv6, whether
> it's full IPv6, or something like 6LoPAN. Any interworking or other issues
> that arise from that choice can be addressed on the far side where there
> isn't such a resource constraint or scaling issue, eg placing an ALG or
> NAT64 in front of the IPv6-only devices to make them reachable by legacy
> IPv4 clients and management systems.
> Even if you assume that smart object deployments aren't going to be
> largely greenfield (which in a lot of cases they are, because the
> infrastructure doesn't exist today), it's almost always going to be easier
> to make changes to the network and other systems to get those to support
> IPv6 than it is to add transition technologies, support dual-stack, or
> retrofit smart object networks from IPv4 to IPv6 later. This is due to the
> scale of deployment and the resource constraints of the device class.
> That's an architectural consideration that drives toward a recommendation
> of single-stack whenever possible.
>
>
>
> Several IAB folks, including two of the authors agreed that this is
> something that should be added, but it has not been addressed in this
> version. In fact, section 2.1 presents IP version as if it is still open
> for discussion on each design, and the other mention of single stack vs
> dual stack in section 4.2 appears to have been removed. I'm hoping that
> this was merely an oversight rather than a conscious decision.
>
>
> Thanks,
>
> Wes George
>
>
>
> On 8/27/14, 2:18 PM, "IAB Chair" <iab-chair@iab.org> wrote:
>
> >This is a call for review of "Architectural Considerations in Smart
> >Object Networking" prior to potential approval as an IAB stream RFC.
> >
> >The document is available for inspection here:
> >https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/
> >
> >The Call for Review will last until 24 September 2014.  Please send
> >comments to iab@iab.org.
> >
> >On behalf of the IAB,
> >   Russ Housley
> >   IAB Chair
> >
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>