Subject: RE: [Rfid] Config vs. control parameters in SLRRP

From: Scott Barvick <[email-masked]>
Date: Fri, 01 Apr 2005 10:58:05 -0500

Great.  I think we are in violent agreement here, and it looks like
there is no hesitation to keep the group from straying into an
artificially limited control protocol or inconsistencies between
configuration and control.

Andrew starts to bring up another topic I think we should explore. 
Margaret also listed it as one of the key things to figure out, and it
is the time requirements on the control that is provided.  

I'll throw out there that I believe that we have a requirement to
provide the ability to approach control at a read cycle level.  This
comes from the opportunity and need to control the richness of the
parameters in the gen2 (and beyond) tags.  This doesn't mean that every
installation or application will need control on this level, but
thinking about it at the per read cycle level will push us to think
about such things as:
- network topologies
- communications overhead and delays
- reader capabilities
- air protocol command exposure
- local, autonomous control requirements.

Scott

On Wed, 2005-03-30 at 13:47, Andrew Funk wrote:
> I want to agree with Suresh here.  I've never wanted to pull what we
> are currently calling "configuration" out of the WG, but there has
> been a strong desire to focus on one segment of the problem space in
> order to make progress.  Scott had suggested during the BOF that the
> initial focus be on the "control" portion, to be followed up by the
> configuration and management activity.  
> 
> If SLRRP is a baseline for the control portion, I had implied that we
> should work through the proposed functionality and make sure that we
> understand what should be embedded in control and what should be held
> out for configuration.  I'm very interested in making sure the right
> protocols and standards are applied to the config side (be it SNMP,
> CIM, whatever), so I believe that should be addressed in the WG as well.
> 
> For example, there has already been extensive discussion of "access-specs".
> One viewpoint holds those as configuration parameters, set-and-forget.
> Another view has that as a parameterization of an inventory command, where
> it might need to be changed on a transaction by transaction basis.  If
> we observe that both cases need to be supported by the work we do, we
> will need to embody a set of default access-specs within any management
> framework we work on (or endorse, if somebody else is already doing it
> appropriately), and the capability, but not the requirement,  to over-ride
> or reset those within the control protocol.  I don't view them as
> exclusive capabilities.
> 
> I'm going to finish by agreeing with Suresh again by stating that we need
> to preserve the coherence of the functionality, but I do think that this
> can be done by aligning the control protocol (SLRRP) with whatever mgmt
> and configuration capability (MIBs,net-conf) are provided as well.  Once
> again, all excellent topics for this WG.
> 
> -Andrew
>  Radfly
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Scott Barvick
> Sent: Wednesday, March 30, 2005 11:19 AM
> To: Suresh Bhaskaran
> Cc: [email-masked]
> Subject: RE: [Rfid] Config vs. control parameters in SLRRP
> 
> We certainly want to make sure that we don't pull out things that are
> needed.  I just wanted to make sure that we discussed
> messages/parameters/functions that might be in question.  I wanted to
> see if anyone had specifics that they wanted to discuss?
> 
> For instance, I believe that the concept of access-specs belongs in the
> protocol, even if there are similar higher level concepts that operate
> within the configuration scope (SNMP, net-conf, etc).  The working group
> would get to the definitions of these operations after specifying the
> control protocol.  
> 
> Scott
> 
> On Wed, 2005-03-30 at 12:32, Suresh Bhaskaran wrote:
> > I agree that configuration also needs to be thought about more.
> > 
> > But artificially splitting (all of) configuration to "outside" the work
> > group may destroy the coherence of the functions.  I like the current
> SLRRP
> > spec because it "fits together", and I can "see" how it fits together.
> > 
> > I think that element should be preserved when we "split off" configuration
> > and "other functionalities" outside the group.
> > 
> > What I loved about the spec the first time I read it was that I could see
> > the big picture "at a glance"!
> > 
> > That element should be preserved, I strongly feel.
> > 
> > Suresh
> > 
> 
> 
> 
> 
> _______________________________________________
> Rfid mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rfid

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