Gabor, thank you for the very comprehensive summary! I'm looking forward to discussion by WG participants and work by the document editors to address and incorporate these issues.
On 1/12/12 6:26 PM, [email protected] wrote: > As the AD noted, the list has been inactive for the last few weeks. > > In this email I am trying to summarize where we are and what we need to do > next in the WG: > > 1. use cases: We had a long discussion about the use cases in the last f2f, > and it seems that the only use case requiring a re-write is the m2m one. > Juan-Carlos promised to revise the use case based on the comments received > and post the revised version to the list asap. > Brian promised to contribute a use case on mesh-networking, as that seems to > be different from the m2m one. > With the revision of the m2m and addition of the mesh-networking one, the use > case part should be complete. > > 2. requirements. In the last f2f > we agreed to modify requirement D.1 to include the suggestions from slide > 7-10 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with > D.6 and D.9 > slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also > contain suggestions on how to revise this requirement. > Agreed to revise requirement D.2 as suggested in slide 11 of > http://www.ietf.org/proceedings/82/slides/paws-2.pdf and slide 9 of > http://www.ietf.org/proceedings/82/slides/paws-1.pdf > We seem to have agreed with the reformulation suggested to D.3 in slide 12 of > http://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on > the format the location would be represented in. The data format part is > still open, but as this piece does not really belong to requirements but > rather the data model spec, we are not in a hurry to decide it. > Delete d.4 > D.5: augment with lower/upper frequencies and time of availability, as > suggested on slide 10 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf > D.6: change power to eirp, as suggested in slide 13 of > http://www.ietf.org/proceedings/82/slides/paws-2.pdf. > D.7: change to single and multiple locations. Clarify that in case of > multiple locations the channel availability for each location should be sent > by the db. > D.8: delete > > P.2 currently says: The protocol MUST support regulatory domain discovery. > We need to discuss this further on the list, to come up with a better > formulated requirement. > The minutes captured: > Implies transmitter first queries the DB to find out the regulatory domain > before it queries for the available channel list > need to spend time figuring out an implementable requirement. Related to > sending "rules" for a domain > put it as a suggestion rather than requirement. Current regulations envision > tight coupling between certified devices and owners. > need to document the coupling between regulatory domain, database, > requirements. > Suggestions for P.2 expected to the list. > > P.3 currently says: The protocol between the master device and the WS > Database MUST support pushing updates in channel availability changes to > subjects. > There were comments that this requirement involves a mechanism, we should > reformulate to be mechanism agnostic. > There was a suggestion to "make the requirement "quick way to change > availability" rather than imply a mechanism.". > The use case is that if the channel availability changes in the DB, the > client has to be able to detect it and get the new availability list within a > time period set by the regulator. > Can someone send suggested text on how to reformulate this requirement? > > We had no time to go through these requirements, so I am asking here on the > list to please comment on them: > > P.4: The protocol between the master device and the WS Database > MUST support mutual authentication and authorization. > > P.5: The protocol between the master device and the WS Database > MUST support integrity and confidentiality protection. > > P.6: The protocol MUST support both username/password and > digital certificates based authentication. > > P.12: A master device MUST be capable of validating the digital > certificate of the WS Database. > > P.13: A master device MUST be capable of checking the validity of > the WS Database certificate and whether it has been revoked > or not. > > Note, P.13 requires support for OCSP (RFC2560) in the client, I am not sure > if that is needed, please send your opinions. > > The wording of P.11 has to be enhanced to match the description of the > revised D.1 > > > We did not have any discussion on P.9, so I'd like to get comments on the > list about this: > P.9: A master device MUST be able to query the whitespace > database for channel availability information for a > specific expected coverage area around its current > location. > > Operational requirements: slides 22-24 of > http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions on > rewording, I propose the editor considers them. > > I ask the editor to implement the changes above and post a revised version > asap, so we can have further reviews on it. > > > We also have a protocol framework document available at > http://www.ietf.org/id/draft-das-paws-protocol-00.txt > We did have a brief discussion on it, the author promised to update it to > capture the received comments and post a new version in the next few weeks. > If you have additional comments, please send those to the list, so the author > can address them. > > We also have a proposal available on the data model structure, available at > http://www.ietf.org/id/draft-caufield-paws-protocol-for-tvws-01.txt > It was presented in the last f2f, but there was no time for comments. Please > send your comments on this document to the list too. > > - Gabor > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
