Subject: RE: [Rfid] SLRRP BoF approved for March IETF meeting

From: "P. Krishna" <[email-masked]>
Date: Fri, 11 Feb 2005 07:51:43 -0500

Hi Daniel,
Its great that you appreciate the relevance and importance of this BoF. We are trying on our end to raise the awareness - I would appreciate it if you and the other folks on the mailing list do the same. 
 
See you in frigid Minneapolis.
 
Thanks,
Krishna

________________________________

From: Soohong Daniel Park [mailto:[email-masked]]
Sent: Thu 2/10/2005 11:08 PM
To: P. Krishna; Scott Barvick
Cc: [email-masked]
Subject: RE: [Rfid] SLRRP BoF approved for March IETF meeting

I make sense of course. However, all attendee is not expert on 
the IETF and further RFID. So I made a comment on the problem
statement/goal stuff which will make them more clear why we should
do this BoF. It's so important point to raise a awaremess of this 
BoF. It's just a individual comment...:-)
 
Anyway, it's of interest in my workground of course.
 
Thanks and see you in Minneapolis.

     Daniel (Soohong Daniel Park)
     Mobile Platform Lab. Samsung Electronics. 

	-----Original Message-----
	From: P. Krishna [mailto:[email-masked]]
	Sent: Tuesday, February 08, 2005 12:15 PM
	To: Scott Barvick; Soohong Daniel Park
	Cc: [email-masked]
	Subject: RE: [Rfid] SLRRP BoF approved for March IETF meeting

	Couple of other differences:
	(i) Access paradigms - in WLAN, clients seek connectivity to the APs and that is the consumer of the RF; in RFID, the RF is consumed by readers performing access operations on the tag. And, there is a rich set of access commands defined over the RF.
	(ii) RF range of the readers are significantly lower than the AP - thus requiring a much denser deployment of readers to provide appropriate coverage; incidentally, the TX power of a RFID reader is much higher than the TX power of an AP - the range is limited because of the energy required to energize the tag. The high TX power however ends up creating reader-to-reader and reader-to-tag interference problems.
	 
	and more ..
	 
	We'll highlight some of these differences in the BOF meeting.
	 
	/Krishna

________________________________

	From: [email-masked] on behalf of Scott Barvick
	Sent: Mon 2/7/2005 6:32 PM
	To: Soohong Daniel Park
	Cc: [email-masked]
	Subject: RE: [Rfid] SLRRP BoF approved for March IETF meeting

	Daniel,
	
	Thanks for your comments.  I also find important similarities between
	the goals of this effort and those of CAPWAP and LWAPP, particularly in
	the area of a control protocol between upstream AR functionality and the
	downstream devices that perform the actual air protocol data and control
	operations.  The 'plugin' support for different air protocols at the AR
	is also similar in concept and spec to the SLRRP support for different
	air protocols. 
	
	One important difference to me is the SLRRP requirement for tighter
	functional and timing control of the air protocol and data operations
	than in my understand of CAPWAP/LWAPP.  In certain environments, the
	SLRRP control of reader parameters could possibly happen as frequently
	as the read cycle.   That will drive certain architectural directions of
	the protocol.
	
	As for the problem statement, we did try to capture it in the proposed
	WG charter, but I can see where we haven't defined the problem as much
	as we have the vision.  I will do a better job for the BoF
	presentation.  If it helps, I am attaching a White Paper that my company
	has produced to help explain the history, current state of the
	protocols, and how SLRRP provides the solution.
	
	Thanks again for the comments.  As we lead up to the BoF, the more we
	work out on the list beforehand, the more productive the BoF will be. 
	
	Scott

	
	On Mon, 2005-02-07 at 01:03, Soohong Daniel Park wrote:
	> Sounds interesting and thanks your good effort.
	> 
	> Mostly, this BoF seems like a LWAPP (Light-Weight Access Point
	> Protocol)
	> for managing of AP in 802.11 environment. and especially AP is
	> replaced with RFID Reader. Anyway, it's interesting work for me.
	> 
	> In my understanding, problem statements (and/or goal) should
	> be done as quick as we can along with the charter of this BoF,
	> because almost people don't know of why this work as BoF is
	> needed for us. SLRRP is a solution not problem statement. So
	> I'd suggest the problem statements would be shown prior to
	> emphasizing SLRRP.
	> 
	> My 2 cents.
	> 
	> 
	> See you in Minneapolis
	> 
	> 
	> Thanks.
	>
	>      Daniel (Soohong Daniel Park)
	>      Mobile Platform Lab. Samsung Electronics.
	>
	>         -----Original Message-----
	>         From: [email-masked]
	>         [mailto:[email-masked]]On Behalf Of Scott Barvick
	>         Sent: Sunday, February 06, 2005 12:10 PM
	>         To: [email-masked]
	>         Subject: [Rfid] SLRRP BoF approved for March IETF meeting
	>        
	>        
	>        
	>        
	>         We have been approved for a BoF (Birds of a Feather) session
	>         at the March IETF meeting.  This is the next step in the
	>         Working Group formation process whereby we meet in an open
	>         session to establish the interest level in the proposed
	>         effort.  We will work through a more specific agenda on this
	>         list, but the general idea is to provide an overview
	>         prsentation of the SLRRP Working Group goals, review the draft
	>         charter, and discuss general architectural directions and
	>         goals. 
	>        
	>         The BoF is not a lengthy session, but it is important for
	>         demonstrating the interest in this effort to the other members
	>         and leadership of the IETF community.  I encourage all who are
	>         interested in moving forward with true standard for RFID
	>         reader network communications and operations to attend this
	>         session.
	>        
	>         I am also pleased to announced that Marshall Rose will be
	>         co-chairing the BoF.  Marshall brings extensive IETF and
	>         networking experience to the table, particularly in the areas
	>         of network management.  I probably won't do him justice on the
	>         career summary front, so I'll let him jump in if he'd like
	>         to:)
	>        
	>         The March IETF meeting will be held March 6-11 in Minneapolis,
	>         MN, USA.  The exact date of the meeting will be sent out as
	>         soon as it is known.   Details for attending the meeting can
	>         be found at http://www.ietf.org/meetings/IETF-62.html
	>         Note that any individual or company can attend the IETF
	>         meetings, even if you haven't done so in the past.  Although a
	>         small fee is charged, that is the extent of the requirements
	>         for participation.
	>        
	>         I have included the BoF charter that was approved below, but
	>         that should just be considered the beginning point for
	>         discussion.  Feel free to post any questions or comments.
	>        
	>         We look forward to seeing you in Minneapolis.
	>        
	>         Scott
	>        
	>        
	>         -----------------------------
	>        
	>        
	>         Chair(s):
	>         Scott Barvick <[email-masked]>
	>         Marshall Rose <[email-masked]>
	>        
	>         Applications Area Director(s):
	>         Ted Hardie <[email-masked]>
	>         Scott Hollenbeck <[email-masked]>
	>        
	>         Mailing Lists:
	>         General Discussion: [email-masked]
	>         To Subscribe:
	>         mailto:[email-masked]?subject=subscribe
	>         Archive:
	>         http://www1.ietf.org/mail-archive/web/rfid/current/index.html
	>        
	>         Description of BOF:
	>        
	>         Radio Frequency Identification (RFID) is a technique whereby a
	>         device,
	>         known as an RFID 'reader', can remotely sense the presence of,
	>         and
	>         access embedded memory on, a transponder, known as a 'tag'.
	>         Tags may be
	>         affixed to objects as a means to track the location and
	>         movement of said
	>         objects within facilities equipped with readers. Tags may also
	>         include
	>         environmental sensors that may capture and report conditions
	>         to which
	>         the tag has been subjected. The tags can be stationary
	>         (attached to
	>         fixed locations in a facility) or mobile (attached to things
	>         moving
	>         about the facility). The readers can be stationary (attached
	>         to doors,
	>         walls, shelving, or scaffolding) or mobile (handheld, or
	>         vehicle-
	>         mounted).
	>        
	>         Recently, as a result of the development of standard RF (air)
	>         protocols
	>         and through the application of low-cost embedded computing
	>         technology,
	>         the implementation of RFID readers has evolved from
	>         peripherals,
	>         typically connected to a host computer via a serial port; to
	>         standalone
	>         devices supporting TCP/IP stacks, connected via wired
	>         (Ethernet) or
	>         wireless (802.11) LAN technology to enterprise computing
	>         resources
	>         supporting RFID-enabled client applications.
	>        
	>         We envision a typical RFID deployment comprising of a network
	>         of RFID
	>         readers controlled by one or more reader network controller
	>         elements
	>         (which may be software in a server, embedded software in a
	>         router/switch, or a standalone device). These controller
	>         elements in
	>         turn are connected to hosts/servers running client
	>         applications that
	>         ultimately consume the acquired tag data and management
	>         applications
	>         that monitor the operation of the reader network.
	>        
	>         This working group will specify a controller-to-reader
	>         protocol, the Simple
	>         Lightweight RFID Reader Protocol, or SLRRP (pronounced
	>         'slurp') for use
	>         in an IP-based network to convey configuration, control,
	>         status, and tag
	>         information to and from readers. This will be the initial
	>         priority of
	>         the working group.  In the future, the working group may
	>         specify
	>         a set of cooperating functions and possibly protocols that
	>         achieve the
	>         level of operations support and management expected of devices
	>         in today's
	>         IP network infrastructure.
	>        
	>         It is possible that work undertaken in other working groups
	>         and even
	>         other standards bodies (e.g. MIBs, discovery protocols) will
	>         be
	>         referenced by this working group.  It is even possible that
	>         entire
	>         deliverables could be satisfied by the work of other working
	>         groups
	>         (e.g. discovery protocols).  This working group will seek to
	>         maximize
	>         the use of existing specifications where applicable.
	>        
	>        
	>         SLRRP Interaction With Other Standards Bodies:
	>        
	>         There are currently two organizations that develop
	>         specifications for
	>         RFID air protocols, ISO and EPCGlobal.  Because the IETF will
	>         not define a
	>         specific RFID air protocol, it is an appropriate venue for the
	>         development
	>         of an air protocol-independent framework for RFID reader
	>         communications and
	>         management.  This is the goal of SLRRP.
	>        
	>         Because this working group seeks to develop operations and
	>         protocols based
	>         on
	>         RFID operations defined in publically available documents,
	>         there is no need
	>         for a formal liason between this working group and other
	>         organizations.
	>        
	>         Members of the working group are encouraged to participate in
	>         the other
	>         standards
	>         development forums so that the proper awareness of
	>         dependencies and
	>         cooperating
	>         functions can be maintained.
	>        
	>        
	>         Goals and Milestones:
	>        
	>         November 04   Post draft-krishna-slrrp-00.txt and draft
	>         working group
	>         charter
	>         (Complete)
	>         Jaunary  05   Post updates to draft-krishna-slrrp-00.txt
	>         Febrary  05   Plan for BoF at 62nd IETF
	>         March    05   BoF at 62nd IETF
	>         April    05   Complete required charter actions
	>         Sept.    05   Submit SLRRP to IESG as Proposed Standard
	>        
	>         Internet-Drafts:
	>        
	>         http://www.ietf.org/internet-drafts/draft-krishna-slrrp-00.txt
	>        
	>         Informational Links:
	>         http://www.iso.org
	>         http://www.epcglobalinc.org
	>         http://www.rfidjournal.com
	>        
	>        

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