Subject: [Rfid] Meeting minutes

From: "P. Krishna" <[email-masked]>
Date: Mon, 06 Dec 2004 14:43:25 -0500

Hello,
We had our first conference call today (12/06/04). Meeting minutes
attached.

Regards,
/Krishna

--------------------------
IETF ROMA WG Meeting Minutes  12/06/04

Attendee list
-------------
Bill Ashley, Impinj
Dan Bailey, RSA
P. Krishna, Reva
Scott Barvick, Reva 
Mike Grady, Reva
Stephan Haller, SAP
Dan Kurtz, W&J

Minutes
-------
Scott: Overview of the ROMA WG description
Key points of ROMA
large reader volume operations
multi-protocol support

Discussion:
Any feedback from IETF to pursue this do you have their blessing?

Scott: As early as Aug, we kicked off this idea. We got support from the
area directors to explore the formation of the group. Subsequent
activity on the mailing list/drafts will help it in moving forward.

How is it different from EPC and ISO efforts?

Scott: Independence of the air-protocol was the strong justification to
move it to an air-protocol-neutral body like IETF. We view this
complimentary to the efforts in EPC like the higher layer protocols.

Isn't there overlap with reader protocol effort in EPC?
Scott: I am a contributor for RP. It doesn't support multiprotocol
effort; deep
support for Gen2 features is absent. I view the RP as web-services
access to
reader operations.  They could be working in different areas of a
system.

There was another comment in favor of using IETF based standards like
RFC for
implementation, but not to use standards orthogonal/compete with
existing standards.

Scott:  Is large reader volume deployment along the path of what others
are thinking in this group?

Bill said that from Impinj's perspective, it is important that our end
customer is able to deploy RFID broadly and economically. Large volumes
are reflected in the statements made in EPC BAG. We are committed to
Gen2 standards.

Scott:  Management/Discovery of readers  SNMP, DHCP are the standard
ways. MIBs developed elsewhere can be reused - as a matter of fact, its
encouraged in the IETF.

Scott:  Security is an important issue. In the past, IETF docs used to
get away
with statements like security is not important/dealt later.  Any
security issues
with doc?

DanB brought up the point about scalable SSL deployments and how we make
that happen. The only issue is that some of the RFCs are based on
web-based transactions; DNS based addressing. Addressing/identification
in large deployments will be key. For example, depending on the
granularity of the security, you may want each antenna as the end-2-end
addressable entities.

Scott:  RF control / Air protocol are important goals. The other
standard bodies
are not addressing it. Not even vendor protocols get to this level of
control. We feel that this level of control is important for supporting
large deployments.

Mike:  We collectively here are exploring the set of essential services
controllable/manageable to support large deployments. We in this group
are
striving to develop a generalized and abstract approach to solve the
problem. The issue is about completeness of a reader operations/control
and
ensuring that we don't have to figure it out every time for every
feature.

DanK mentioned that when they build a new reader, they wonder about the
protocol
commands to support.  They may need to look at other vendors to see what
to expose.

Bill pointed out that there are capabilities in the current tags (C0/C1)
that
are not exploited to that. E.g., fair amount of R/W memory letting the
customers
to access them is invaluable.  Class 2, 3 will have additional access
capabilities.

We discussed starting a thread about some other features, even in
current
generation tags, that could be exposed at this level of protocol. 
Different
access methods was one.  DanK will start a thread to capture these.

We had a discussion about what is decribed for Gen2 specifically.  Bill
thought
that SLRRP provides a fairly low level control the air/RF control. This
protocol goes further than any
other protocol in trying to control the Gen2 network.  Advantage to
specifying structure helps in interoperability. Leaving it to reader
vendors to specify the low-level controls will lead to proprietary
implementations.

Scott  Contributions are welcome for feature requirements/feature goals,
C0/C1, ISO standards.
-----------------------------------------

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid