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? 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. 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. 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
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
