Gabor. This draft represents the merger of two submitted proposals, one from Das/Gabor from Telcordia and one from Peter/Don from SBI prior to the last meeting. These individuals have worked to create a single proposal for this upcoming meeting. This attempt at a merger was a request from the last meeting and was acted upon so I do not understand why you think there has been no discussion. I do not agree with your assertion that the data model needs more work. For example your assumption that an iCalander element is needed. You assume that a 24 hour channel map is provided. There is no reason to require this. In fact there is ongoing discussion in the US to migrating to much shorter channel allocations and it is reasonable to have a channel map that is valid for a duration until such time as something changes. In other words the DB provides a channel map that is valid from now until some time in the future, which may be much less than 24 hours. Peter S.
On SatJul/21/12 Sat Jul 21, 7:30 PM, "[email protected]" <[email protected]> wrote: >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
