Gabor, Thanks for your comments. We separated the two sets of functions to allow for (as described in the document) the general ability for the Master Device to establish communications with the Database in the INT-REQ and used the REG-REQ for the specific purpose of supporting the requirement for a Fixed Device to register its location and owner information as per the FCC rules. They could be combined; however, it seemed clearer to separate out the optional requirement of the Fixed Device registration into a separate well defined function.
Regarding the data model using vCard and iCalendar are reasonable implementations however including these packages may be cumbersome and overkill for the one or two elements that need to be communicated. One of the design principles we were considering in the draft proposal was to keep the interface light weight. Looking forward to the discussion in Vancouver. Regards, John Malyar ________________________________________ From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]] Sent: Saturday, July 21, 2012 7:30 PM To: [email protected] Subject: [paws] comments on draft-das-paws-protocol-02.txt It would be beneficial if there were discussions on the drafts to submitted ahead of the F2F presentations. Thus, I've taken the initiative to read the draft and provide some initial comments: 1. I do not understand the purpose of the initialization process and why messages INT-REQ and INT-RESP are necessary. The capability exchange can be done during the registration process. We may even consider merging the registration process with the DB query process, there doesn't seem to be any reason to have them as separate messages. 2. you may need a section where you map your newly defined messages to existing http protocol messages. I saw that you have an example section, but a normative section would be more desirable. 3. the data model part needs some more work. The structure is not very clear to me, and some of the attributes reference obsolete RFC. Eg, RFC3825 is referenced for the longitude/latitude attributes. I think you should be better of using an element for geo-location, with the structure as defined in RFC5491, a separate element for the civic location, with the structure as defined in RFC5139, etc. Instead of the DeviceOwner object, I would use a vCard element, with the structure as defined in RFC2426. You may also need an iCalendar element (RFC5545) to specify the channel availability time (eg, when the channel is not available for the full 24H). Etc. More comments are welcome. - Gabor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Das, Subir Sent: Saturday, July 14, 2012 7:36 AM To: [email protected] Subject: [paws] FW: New Version Notification for draft-das-paws-protocol-02.txt Dear Chairs, We have updated our draft and would like to request a slot in IETF-84 to present it. Regards, _Subir -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Saturday, July 14, 2012 10:30 AM To: Das, Subir Cc: [email protected]; [email protected] Subject: New Version Notification for draft-das-paws-protocol-02.txt A new version of I-D, draft-das-paws-protocol-02.txt has been successfully submitted by Subir Das and posted to the IETF repository. Filename: draft-das-paws-protocol Revision: 02 Title: Device to Database Protocol for White Space Creation date: 2012-07-14 WG ID: Individual Submission Number of pages: 32 URL: http://www.ietf.org/internet-drafts/draft-das-paws-protocol-02.txt Status: http://datatracker.ietf.org/doc/draft-das-paws-protocol Htmlized: http://tools.ietf.org/html/draft-das-paws-protocol-02 Diff: http://tools.ietf.org/rfcdiff?url2=draft-das-paws-protocol-02 Abstract: This document describes the `Protocol to Access White Space database (PAWS)' that uses HTTP/TLS as transport. The protocol is used for retrieving the necessary TV white space information (e.g., channel, frequency, transmitted power) at a given location and time from a database that is operating under a regulatory domain. The document includes the protocol functionalities, its elements, corresponding data model and recommends its encoding scheme. The IETF Secretariat _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
