Sorry for the delayed response.
On Wed, Dec 18, 2013 at 7:00 AM, <[email protected]> wrote: > Thanks Vincent for the clarifications. Few inline comments below. > > > > Best Regards, > > Sajeev Manikkoth > > > > *From:* Vincent Chen [mailto:[email protected]] > *Sent:* Tuesday, December 17, 2013 12:34 AM > *To:* Sajeev Manikkoth > *Cc:* [email protected]; [email protected] > *Subject:* Re: [paws] wglc on > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > > > Sajeev, > > > > Thanks for your comments. Answers inline. > > > > On Fri, Dec 13, 2013 at 9:54 PM, <[email protected]> wrote: > > Hi, > > > > Please find few comments based on my review of the new draft spec: > > > > 1. In AVAIL_SPECTRUM_REQ all parameters are shown optional. Does that mean > an empty request is ok? As 'Device descriptor' is required in response, > same should be the case in request too. > > > > An empty request is not OK. Each field, independently, may be optional, > but the descriptions describe when they are required. > > There are some dependencies between the parameters. For example, if > "requestType" is for getting generic operating parameters, > > which may be allowed by ETSI, then the DeviceDescriptor is optional. > > *[Sajeev>>] Is it going a bit complex this way with parameter > dependencies?* > *[vchen] I believe this is a trade-off between adding more fine-grained "rpc methods" versus fewer methods with more optional parameters.* *At the end of the day, the complexities are equivalent, if you want to support the different use cases. * > > > In light of this, perhaps Device Descriptor in the response should be > optional. > > > > Also instead of 'location' and 'Master Device location', it will be > better to include 'location' and an optional 'Slave Device location' in > case request is on behave of slave, as Master is the default request entity. > > > > This is a matter of opinion, I suppose. I believe it is more consistent to > have "location" and "deviceDesc" be associated with the > > target device and "masterDeviceLocation" and "masterDeviceDesc" be > associated with the "master". > > > > Avail spectrum request can also include an optional time range, so that > database can send a filtered and useful set of spectrum for the given time > range, than the full set. > > > > I'm not sure this is consistent with the rules. The Database may be > required to provide the availability for the next N hours. > > I'd like to see other opinions on this point. > > > > > > 2. In SPECTRUM_USE_NOTIFY message 'spectra:list' parameter can include the > time range which the device intend to use the spectra, to improve QoS and > avoid too many request/response messages between master and database > > > > Although it might be a good idea to include the time range which the > device intends to use the spectra, I'm not sure how that improves QoS or > reduce the number of messages? > > *[Sajeev>>] Secondary user service disruption due to primary or another > user using the frequency can be reduced if a time range is negotiated and > accepted. Also during the accepted time interval master need not further > query the db on the frequency/channel which negotiated. * > *[vchen] I believe this is already addressed. Certain classes of primary users (wireless mics) already have the ability to reserve spectrum (independent of PAWS), and the Database responses to secondary user must take that into account. The database response is a schedule of available spectrum that is valid for a specified duration, and the Master does not have to contact the DB again during that duration.* *To offer additional coordination between secondary users is out of scope, but a Database may extend the protocol (as a value add feature).* > > > > > 3. Diagram in Section 4.5, which shows messages between master and device > can use different message tokens than the tokens used between master and > database. Which will make it explicitly clear that they are not the same. > > > > It is subtle, but the figure already uses different line styles for the > two cases. > > > > > > 4. Section 5.2 Device Descriptor can include a parameter to specify > 'Mobile' or 'Fixed' device > > > > The regulatory domain defines device types, which, typically, are > associated with mobile or fixed. > > *[Sajeev>>] Yes, and in the request master can publish it through a > parameter was my point here. Perhaps this can help db to decide on the > available spectra for the device type.* > > > *[vchen] The Database is already supposed to take device type into account. The regulatory rules require it. That is, the rules prescribe what spectrum is available and the power levels, based on device type.* > > > 5. Section 5.4 Device Capabilities can include Power Range of the device > too. > > > > This might be a reasonable extension, but probably would not fit in this > first version of the protocol. > > - Currently, the Database is responsible for informing the device the > maximum allowed power levels, regardless > > of the power-range capabilities of the device. > > > > - Device Capabilities can be quite complex to express, and it would be > better to tackle this later. > > > > > > > > 6. Section 5.9 "The SpectrumSpec element encapsulates the schedule of > available spectrum for a regulatory domain". Should this also include a > specific location area? > > As a regulatory domain may include a large location coverage, and reuse of > licensed spectrum in different locations. Is there a need of location area > coverage parameter in the device descriptor? > > > > I believe this is already addressed: > > > > In the current and proposed rules, the Device must request new spectrum if > it moves by more than X distance. > > For Databases that support request by region, it is expected that the > Database returns spectrum that is allowed > > anywhere within the region. > > > > > > 7. Section 5.17 - Error codes. As the PAWS protocol is over HTTPS, not > using the same(HTTP) 1xx, 2xx, 3xx status codes looks like a better option. > Use of another range or 4/2 digit codes will avoid confusion. > > > > These define error codes at the protocol level. > > > > When the binding is JSON-RPC over HTTPS, the HTTP error codes at the > transport level still apply. > > (e.g., 3xx redirect, 5xx server errors, etc.) > > > > > > > > > > Best Regards, > > Sajeev > > > > > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
