On 10/29/12 7:53 AM, Peter Stanforth wrote:
I don't think we can ignore the "Regulator". You may not need to know what
a radio does or how it works but the database is logically tied to a
Regulator.
In all the cases we are aware of the Database will either be operated by
the Regulator or by an entity (or entities) authorized by a Regulator.
Spectrum use is tightly regulated - the regulator makes the rules. There
are many examples of things that are included in this protocol that you
could argue would not normally be required for a protocol. They are only
there because Regulators require them.

I think you've missed the point. It is certainly clear that we need to take into account requirements that come from regulators. But it is the requirements that are important, not where they come from. For example, in other IETF protocols, we may have requirements from industry that certain things are NETCONF manageable. That might not normally be required for a protocol, but because they are required by a particular industry, they are requirements for our protocol design. That doesn't mean that we say, "MUST follow all requirements of the widget industry". We say, "MUST be NETCONF manageable." The industry is irrelevant to the document; it's the requirement that matters.

Concentrating on the regulator also obfuscates real requirements. Regulatory language is almost never in appropriate engineering terms. People must figure out what the engineering requirement is from the regulatory language. Conversely, if a regulatory statement seems to indicate something that is contrary to the correct engineering outcome, we have to figure out how to do the engineering with the requirement or get the requirement fixed. Knowing it comes from a regulator doesn't help us.

There is nothing special, from a protocol engineering perspective, that the requirements come from a regulator. Having references to the regulator is either inappropriate or is hiding missing information that we need to have in the document. Of the items that I specifically pointed out in the document, I can find nothing that mentioning the regulator adds to the text. If you can point one out that makes a difference, please do.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws

Reply via email to