[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SLP reference architecture I-D
At 01:03 AM 3/27/2000 +0300, EXT john.loughney@nokia.com
wrote:
>* Each appears
to be very Wireless specific (constant references to
>GPS as the representative format for location) -- which this BoF
hasn't
>determined is the foundation for its objective in my opinion; We
haven't
>narrowed anything down yet -- if we're going to at all;
>[<JAL> ] Of course, wireless has some immediate needs/uses
for location.
>Perhaps the draft can be more neutral in it's terminology, and
wireless
>devices used as examples only.
How about slanting the I-D towards Wireless in the Title or in the
Abstract/Introduction. Were that the case, I would have not commented as
strongly as I did. I'm trying to not limit anything -- therefore I'm
pushing views that are brought to my attention away from limiting
mechanisms or approaches for now -- especially I-D's with broad
implications that don't self limit the target audience. Does this make
sense?
I guess if the Title was "Wireless Architectural Considerations
for Spatial Location" with similar Abstract/Introduction matching
that goal .... I would have said "great I-D with great ideas"
and we would go from there forward (instead of this minor side-step).
Fair?
>
>* These I-D's
seem also to be very SIP-centric for Signaling Protocols
>-- shouldn't this Spatial Protocol be independent of any other
signaling
>Protocols by nature?
>[<JAL> ] First, I believe that SIP is an example moethod,
not a requirement.
>I think that the BOF needs to determine if a new protocol needs
to be
>developed, or recommendations for existing protocols to be
enhanced. I've
>seen quite a few protocols put forward as possibilities, but I
am not
>experts many of them, so I think that we should review all
options.
I don't yet see how a Voice Signaling Protocol should be a transport
for this (I know Jonathan Rosenberg doesn't either BTW) -- but it could
work out that way.
SLoP should have a goal of a new Protocol working in conjunction
with, or parallel to, other Protocols, at this point at least (again
IMO)
>
>* Both your
"Security Considerations" section mention "The
>communication between the various entities transporting location
information
>data MUST be secure" -- but don't explain if or how a PDA
or Cell Phone will
>establish a viable Security Association with 'the other device'
with an
>acceptable Cipher or key length?
>[<JAL> ] This section definately needs to be
addressed. This is a definate
>point for discussion.
Fair.
>
>* Both I-D's
seem to indicate the user enters their device's location
>in order to send that information to another device; I shouldn't
trust this
>method, should I?
>[<JAL> ] If a device is static, it might have its location
configured (no
>GPS, triangulation available), so the location may be manually
entered. My
>feeling is that if you trust the user, then you probably trust
the user's
>data. Now, if you are saying that manually configuring
location may not be
>sufficient, that is debatable (pro & con).
I work in Security and know I shouldn't trust anything from
something I don't have a "Trust Relationship with" (with that
establishment done in many ways). I believe there needs to be a Trusted
Server Architecture in place for reliable and Trustworthy Location
information communications.... but I could be in the minority here
too.
>
>As a result of this -- I (as a Co-Chair) would prefer
that
>"draft-nyckelgard-isl-arch-001.txt" (or any other
Individual Submission) not
>be called the "Reference" or "Architecture"
in the title until many more of
>these issues be worked out. Agreed?
>
>[<JAL> ] Let's talk in Adelaide about this, as this
document meant to
>consider the architecture in advance of any architecture
existing.
fair
>
>cheers,
>John
>
>
*************************************
"At the end of the day... the most committed win!"
James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f) 972.813.5280
www.cisco.com