RE: Requirements Document

I wrote this before I saw your mail on your interpretation
of the charter. So, from your point of view, this is mostly
meaningless, but I think you are incorrect, so I offer it anyway.

I don't really understand how you intend to accomplish our
goals. We are defining the requirements for an object. We
aren't defining a protocol, and FOR SURE, we are going to
use this object in existing protocols with existing devices.
SIP and HTTP are examples, on existing phones and PCs at a minimum.
Sure, new devices with new capabilities will come along;
I'm working on some :), but whatever we do, it has to WORK
on a "black" phone connected to a SIP gateway, or a current
technology WAP phone, or the first gen 3GPP phones, and, believe
it or not, the first level ethernet switch in the closet near
you.

A critical need, my first application of this object, is to
reveal location in an emergency call. Please tell me what
SIP messages you want me to send and receive in order to
send location. Yes, we can if needed, modify SIP, although
it might be hard to totally redefine the protocol.

Please keep in mind the current bandwidth available to a 3GPP
telephone for signalling (around 4Kbits), and the current processor
available to run cryptographic operations. I don't care
what the future will bring if the REQUIREMENTS must be met
by current technology. What REQUIREMENTS are you placing
on my current problem?

Hmmm, I just listed several requirements. Let me restate them:
1. The solution must be retrofitable into existing protocols such
as HTTP and SIP.
2. The solution must function on existing technology SIP gateways
existing WAP-style mobile devices, first generation 3GPP handsets
current generation PC technology, and existing first level manageable
LAN switches. Software upgrades are acceptable.
3. The solution must function on low bandwidth (e.g. kilobit-range)
links with reasonable response times.
4. The solution must support high-update-frequency tracking
5. The solution must support unattended devices

Brian

> -----Original Message-----
> From: John W Noerenberg II [mailto:jwn2@qualcomm.com]
> Sent: Thursday, August 23, 2001 6:26 PM
> To: Rosen, Brian
> Cc: 'Randy Bush'; geopriv@mail.apps.ietf.org
> Subject: RE: Requirements Document
>
>
> At 9:20 AM -0400 8/23/01, Brian Rosen wrote:
> > > >There certainly is scope for dealing with agents that are
> >> across the wire
> >> >from the sender (I send location to a server that
> authenticates and
> >> >provides my location to others on my behalf).
> >>
> >> There are senders and receivers. What you are talking about is a
> >> receiver who may become a sender, and calling this
> receiver-sender an
> >> "agent". I'm just clarifying terminology.
> >Yes, you have interpreted what I meant correctly.
> >
> >>
> >> > I want the object to be able to be used in such a circumstance.
> >> >The issues of how the delegation is done, and how the
> authentication
> >> >between the ultimate receiver and my agent is, I think,
> also beyond
> >> >any strict requirement.
> >>
> >> I disagree. The delegation rights for the information must be
> >> encoded in the location message.
> >I agree that it COULD be, for some uses, although I suspect that
> >in fact the delegation for the vast majority of the cases is
> >in fact more static, and received out of band. With respect
> >to our work, I can see writing up some requirements for a
> >such a case as an example, but I would be against mandating the
> >mechanism. Thus my opposition to a strict requirement.
>
> Our goal is to insure that location information is revealed in
> compliance with the agreement between the sender's controller and the
> receiver's controller. We must assume that each transaction is
> independent. Therefore the access rights applying to any particular
> transaction must be included in every transaction. To do otherwise
> allows the condition that location revelation is not controlled by
> security considerations in every circumstance. This would be a
> fundamental flaw.
>
> >
> >We can say something like, "where it is appropriate, delegation
> >of rights could be sent with the location message. In such a
> >case, protocol designers may consider the following requirements."
> >
> >What you can't do is state absolute requirements, because they vary
> >greatly by use case.
> >>
> >> > My agent could receive my delegation by out-of-band means. It
> >> >could authenticate by out-of-band means.
> >>
> >> I suppose it could. But why is that desirable? Even if it is, we
> >> still need a way to change the delegation privileges in-band. We
> >> don't want to force people to go out-of-band to change
> the delegation
> >> privileges. That would be inconvenient in many circumstances.
> >
> >It is desirable because the UI for the end device may be much less
> >convenient to allow a full and complete disclosure of when and
> >under what circumstances delegation is permitted.
>
> I say with all respect, the UI capability of the end device is not
> our primary concern. First, we must create a protocol which insures
> privacy considerations of sender and receiver are respected to the
> greatest degree possible.
>
> >A much more reasonable scenario is that you sign up for a
> service which has
> >a website where your contract is spelled out. You may have a number
> >of controls, best managed by a desktop UI. You make your choices,
> >come to agreement, and then your end device makes reports to
> the service
> >and the service does the delegation.
>
> This is only reasonable in terms of devices which were designed
> several years ago. Do not be bound by this. We must not be bound by
> this. We are designing for devices to be built tomorrow, not
> yesterday.
>
> >
> >I don't want to force anything on anybody. I want to make services
> >available.
> >I want options, not restrictions. I'll be very happy to accommodate
> >any of the mechanisms you want to see, as long as every one of them
> >is optional to implement.
>
> If they are optional, they are meaningless.
> --
>
> john noerenberg
> jwn2@qualcomm.com
>
> ----------------------------------------------------------------------
> Like the Sorcerer's Apprentice, we succeeded beyond our
> wildest dreams and our worst fears.
> -- Steve Crocker, quoted in Wired Magazine, Apr, 1999
>
> ----------------------------------------------------------------------
>
Received on Fri Aug 24 08:28:50 2001