Hi Scott,
I checked the requirements against ECC report 159 requirements
(section 9.3.3 / 9.3.4 starting at page 69).
I think we miss:
9.3.3:
- location with height, with MAY on uncertainty on height (2nd bullet)
==> add in D.4
- device type (class of device, 3th bullet).
==> add in D.2
...> although device ID would tell the device type
- expected area of operation, a SHOULD or MAY (5th bullet)
==> extension to D.4, D6 or new requirement
==> D.6 describes multiple locations, where ECC-195
describes an area (circle, polygone) and movement.
9.3.4:
- maximum transmit power (2nd bullet)
==> add in D.5
- wsdb redirect (2rd bullet)
==> this MAY / SHOULD be a mechanism besides the wsdb
discovery as described in 5.3 or 1st step in P.1
- requirement for sensing (5th bullet)
==> this is a MAY or SHOULD, to be added in D.5
Other remarks on requirements:
P.10: fix typo (searial")
I suggest we specify the protocol MUST support all data model elements
in D.1 to D.6. Then, the P.* can be cleaned up a bit.
P.7 to P.13 are not protocol requirements. Maybe reword so these
are requirements for the protocol, or make a new section for
requirements for master devices. Or put it in operational requirements.
Question on D.1: are all parameters for data the master sends to wsdb?
The second line "... of the subject, ..." is a bit fuzzy.
Maybe add "subject" in 2.2 :-)
Subject
A person or thing that is being discussed,
described, or dealt with.
Or scan the document on "subject" and try to replace. Maybe we need
a term for device that can be Master Device and / or Slave Device.
ECC-159 uses White Space Device (WSD).
White space device
White space devices (WSDs) are devices that can use White Space
spectrum without causing harmful interference to protected services
by employing required cognitive capabilities.
Thanks, Teco
> Hi,
>
> Revision 2 of the PS, Use cases and requirements I-D has been posted. Please
> see:
> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt
>
> This version only includes changes requested by the co-chair in his email of
> January 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.html
> Specifically:
> "
>> 2. requirements. In the last f2f
>> we agreed to modify requirement D.1 to include the suggestions from slide
>> 7-10 ofhttp://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.pdfand 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
>> ofhttp://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 ofhttp://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
> "
>>
> And
> "
>> 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.
> "
>
>
> Regards,
> Scott & Raj
> _______________________________________________
> paws mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
