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

From: Scott Barvick <[email-masked]>
Date: Wed, 30 Mar 2005 09:07:50 -0500

Andrew pointed out that the current SLRRP draft is not consistent with
the proposed WG charter of focusing on control commands vs.
configuration.   Can we get this out on the list?  This will help
further clarify the difference.  

Margaret also brought up the question about the definition of
access-specs and whether they are config or control.  This also deserves
more discussion.

Scott

On Thu, 2005-03-24 at 10:37, Andrew Funk wrote:
....

>I would also like to see the group be more explicit on what represents
>"management" functionality that will be dealt with at a later time, because
>the current SLRRP draft is peppered with fields and a few commands that
>could arguably be construed as management functions.   This isn't a WG
>scoping problem, just work that needs to be done by the WG.

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

---

From: "Suresh Bhaskaran" <[email-masked]>
Date: Wed, 30 Mar 2005 09:32:15 -0800

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Scott Barvick
Sent: Wednesday, March 30, 2005 6:08 AM
To: [email-masked]
Subject: [Rfid] Config vs. control parameters in SLRRP

Scott

---

From: Scott Barvick <[email-masked]>
Date: Wed, 30 Mar 2005 13:19:18 -0500

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

---

From: "Andrew Funk" <[email-masked]>
Date: Wed, 30 Mar 2005 11:47:07 -0700

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

Scott