Re: [Rfid] Control Plane Architectural Elements

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