Re: [Rfid] Control Plane Architectural Elements
Margaret Wasserman <margaret@thingmagic.com> Fri, 22 July 2005 21:16 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4sD-0006aP-P3; Fri, 22 Jul 2005 17:16:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4s9-0006Yd-9O for rfid@megatron.ietf.org; Fri, 22 Jul 2005 17:15:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27918 for <rfid@ietf.org>; Fri, 22 Jul 2005 17:15:54 -0400 (EDT)
Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw5MR-0000SB-LZ for rfid@ietf.org; Fri, 22 Jul 2005 17:47:17 -0400
Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 449160; Fri, 22 Jul 2005 17:09:38 -0400
Mime-Version: 1.0
Message-Id: <p062007d8bf070e41fb7a@[192.168.1.105]>
In-Reply-To: <1122064335.27520.124.camel@saco.revasystems.com>
References: <p062007d3bf06f09306d8@[192.168.1.105]> <1122064335.27520.124.camel@saco.revasystems.com>
Date: Fri, 22 Jul 2005 17:15:44 -0400
To: Scott Barvick <sbarvick@revasystems.com>
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: Re: [Rfid] Control Plane Architectural Elements
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: rfid@ietf.org
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Control and Access of Infrastructure for RFID Operations Discussion List <rfid.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rfid>
List-Post: <mailto:rfid@lists.ietf.org>
List-Help: <mailto:rfid-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=subscribe>
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org
Actually the architectural diagram I sent is quite consistent with the EPC Global architecture -- you can view ALE as the multi-reader controller and RP as the single reader controller. Both interfaces might be exposed by a smart reader (for different types of applications/middleware), and so I think that there is a large benefit to having them be consistent (i.e. having them use the same terminology for the same concepts, and the same respresentations for shared data types, etc.) For example, I am not sure how you can claim that the fact that XML is used at a higher-level interface argues _against_ it being used at a lower level. Quite the opposite, I would think. Also, I wonder how we can design a reader control protocol that is consistent with the EPC Global architecture given two important facts: (1) We (the whole IETF community) can't see the current versions of the EPC Global architecture and the protocols that would exist on top, below and beside this protocol, because documents under development in EPC Global are only available to members, and (2) EPC Global already has a effort for every protocol included in their architecture, so we would presumably be developing a suite that is a technical competitor to theirs. Is it your idea that the IETF reader control protocol would be required to plug into the EPC Global architecture in the place of the RP element? Or the RP and RM elements? Or the RP, RM & ALE elements? Your current and future charter items seems to range pretty far outside of RP alone. The last charter I saw is certainly not clear on this point, as it refers to EPC Global as an "air interface standards body", which is about as inaccurate as referring to the IETF as a "layer 3 standards body". >Therefore, I think we need to stay more true to the CAIRO proposed >charter until the group and/or Bert/IESG decides to change it to take it >in a different direction. We have made a lot of progress with the spec >and resulting implementations on the reader, RNC, and tools ends of >things based on the current charter proposal, and I strongly recommend >we stay focused. I am not really sure what this means... Are you saying that discussing whether or not SLRRP is based on the right architectural and technical choices is out-of-scope for this WG and that we are just here to standardize SLRRP more-or-less as-is? This isn't even an IETF WG yet, so being so set on a particular solution at this point doesn't seem reasonable to me. As far as I know, only one vendor was involved in the definition of SLRRP and few (if any) reader vendors have been significantly involved in its evolution. I also have to admit to being somewhat uncomfortable about the fact that someone from Reva is shutting down discussion about whether or not SLRRP is the correct architectural choice, given that this is currently your company's proprietary protocol. Does that seem at all strange to you? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid
- [Rfid] Control Plane Architectural Elements Margaret Wasserman
- Re: [Rfid] Control Plane Architectural Elements Scott Barvick
- Re: [Rfid] Control Plane Architectural Elements Margaret Wasserman
- Re: [Rfid] Control Plane Architectural Elements Margaret Wasserman
- RE: [Rfid] Control Plane Architectural Elements P. Krishna
- RE: [Rfid] Control Plane Architectural Elements Margaret Wasserman
- Re: [Rfid] Control Plane Architectural Elements P. Krishna