Add support for wireless regulatory provisioning

jaylogue commented 4 years ago

PROPOSED: Extend the Weave Network Provisioning profile with features to support runtime provisioning of wireless regulatory configuration on devices.

To support wireless regulatory provisioning, it is proposed to extend the Network Provisioning profile with three new message types, comprising two new protocol patterns.

SetWirelessRegulatoryConfig (msg type 15)

The SetWirelessRegulatoryConfig message updates a device with new wireless regulatory configuration information. Information conveyed with the message describes the operating location of the device with respect to regulations governing wireless radio transmissions. The payload of a SetWirelessRegulatoryConfig message consists of the following TLV structure:

SetWirelessRegulatoryConfigArguments [anon] => STRUCTURE
{
    /** ISO 3166-1 country code, or “00” for world-wide.
     */
    regulatoryDomain [1, optional] : STRING [len 2],

    /** Operating location relevant to wireless regulatory rules.
     */
    operatingLocation [2, optional] : UNSIGNED INTEGER [range 0..255]
    {
        reserved = 0,  /* may not be sent. */  
        unknown = 1,
        indoors = 2,
        outdoors = 3
    }
}

The regulatoryDomain argument must identify the country in which the device is or will be operated, OR another country that is subject to the same or compatible regulatory rules as the operating country. Additionally, the special value “00” may be supplied to indicate the device should operate in a mode which is compatible with all regulatory rules world-wide.

The operatingLocation argument identifies a logical location in which the device is or will be operated that may be relevant to the regulatory rules of the operating country. This value is an integer enumeration that may be extended over time. The unknown operating location signifies that the device's specific operating location is not known, or that it may change over time. (Note that the reserved value may not be sent in any message).

The values specified for regulatoryDomain and operatingLocation govern the transmission behavior of all radios built-in to the device. This includes WiFi and 802.15.4 radios, if so provisioned. The effects of setting wireless regulatory configuration should be persistent on the device at least until the device is factory reset.

Either or both the regulatoryDomain or operationLocation arguments may be absent in a SetWirelessRegulatoryConfig message. If an argument is not present, then its corresponding current value on the target device is not changed.

The response to a SetWirelessRegulatoryConfig message is always a Common:StatusReport message containing the status of the request. Devices that do not support the SetWirelessRegulatoryConfig message must return the Common:UnsupportedMessage status. If a device supports the SetWirelessRegulatoryConfig message but does not support the specified regulatoryDomain, it must return the status code NetworkProvisioning:UnsupportedRegulatoryDomain (12). If a device does not support the specified operatingMode, it must return the new status code NetworkProvisioning:UnsupportedOperatingLocation (13).

Devices must implement suitable access controls for SetWirelessRegulatoryConfig requests. In general, requests should be subject to the same access control rules as NetworkProvisioning:AddNetwork requests.

A SetWirelessRegulatoryConfig message must always be the first message in a Weave exchange, and the Common:StatusReport response to the message always marks the end of the exchange.

SetWirelessRegulatoryConfig Protocol

GetWirelessRegulatoryConfig (msg type 16)

The GetWirelessRegulatoryConfig message fetches the wireless regulatory configuration information from a device. The GetWirelessRegulatoryConfig message has no payload.

The response to a GetWirelessRegulatoryConfig message is either a GetWirelessRegulatoryConfigComplete message if the request was successful, or a Common:StatusReport message containing an error status. Devices that do not support the GetWirelessRegulatoryConfig request must return the Common:UnsupportedMessage status.

Devices must implement suitable access controls for GetWirelessRegulatoryConfig requests. In general, requests should be subject to the same access control rules as NetworkProvisioning:GetNetwork requests where network passwords are not being requested.

A GetWirelessRegulatoryConfig message must always be the first message in a Weave exchange. The response to the GetWirelessRegulatoryConfig message (either a GetWirelessRegulatoryConfigComplete or a Common:StatusReport) always marks the end of the exchange.

GetWirelessRegulatoryConfig Protocol

GetWirelessRegulatoryConfigComplete (msg type 17)

The GetWirelessRegulatoryConfigComplete message conveys wireless regulatory configuration information from a device in response to a GetWirelessRegulatoryConfig message. The payload of a GetWirelessRegulatoryConfigComplete message consists of the following TLV structure:

GetWirelessRegulatoryConfigResults [anon] => STRUCTURE
{
    /** ISO 3166-1 country code, or “00” for world-wide, or
     * null if unknown.
     */
    regulatoryDomain [1] : STRING [len 2, nullable],

    /** Operating location relevant to wireless regulatory rules,
     * or null if unknown.
     */
    operatingLocation [2] : UNSIGNED INTEGER [range 0..255, nullable]
    {
        reserved = 0,  /* may not be sent. */  
        unknown = 1,
        indoors = 2,
        outdoors = 3
    },

    /** List of support regulatory domains.
     */
    supportedRegulatoryDomains [3] : ARRAY OF STRING [len 2]
}

The regulatoryDomain result identifies the country whose regulatory rules the device is operating under, or “00” if the device is operating in a mode which is compatible with all regulatory rules world-wide.

The operatingLocation result identifies the regulatory-specific logical location in which the device has been configured to operate.

The supportedRegulatoryDomains result contains a list of all country codes that the device is capable of accepting in the regulatoryDomain argument of a SetWirelessRegulatoryConfig message. The list must NOT include the “00” special value.

A device implementation may opt to not persist either or both of the regulatoryDomain and operatingLocation values, choosing instead to persist internal radio settings corresponding to effective regulations implied by those values. In this case, a device can return null for the regulatoryDomain and operatingLocation values. Note that the unknown operatingLocation value should not be returned in this case.

The GetWirelessRegulatoryConfigComplete message must only be sent in response to a GetWirelessRegulatoryConfig message, and therefore can never be the first message in an exchange.

jaylogue commented 4 years ago

@gerickson, @robszewczyk, @mrjerryjohns : Based on recent discussions, it has been suggested that the Network Provisioning profile be extended to support wireless regulatory configuration during OOB, as needed by some products. Here is a proposal for how I see that working. Let me know what you think.

gerickson commented 4 years ago

We've had a body of historical and currently-active work on this front in Nest and Google Nest products to date. I've shared an internal document that memorializes that work.

It mostly harmonizes with the Linux Wireless Regulatory Database and CRDA where the Indoor / Outdoor notion here is represented there as FLAGS:

Flag	Description
NO-OFDM	OFDM modulation not allowed.
NO-CCK	CCK modulation not allowed.
NO-INDOOR	Indoor operation not allowed.
NO-OUTDOOR	Outdoor operation not allowed.
DFS	Dynamic Frequency Selection (DFS) is required.
PTP-ONLY	May only be used for point-to-point links.
PTMP-ONLY	May only be used for point-to-multipoint links.
PASSIVE-SCAN	Passive scanning is required (no active (probe) scans are allowed).
NO-IBSS	Independent Basic Service Set (IBSS) (ad-hoc) networks are not allowed.

If we can see a path to only doing here what's necessary for use cases in front of us while extending to incorporate the fullness of "Linux Wireless Regulatory Database and CRDA" in the future, if needed, then I think we're good.

That document also describes values for operatingCountry as:

Mnemonic	Code	Description
kRegulatoryDomainUnknown	??	Unknown or unspecified domain.
kRegulatoryDomainWorldwide	00	World-wide, restrictive domain.

Table 1. Other Regulatory Domain Codes

Mnemonic	Code	Description
kRegulatoryDomainAgencyDOC	A0	Canadian Department of Communications
kRegulatoryDomainAgencyIC	A0	Industry Canada
kRegulatoryDomainAgencyETSI	A1	European Telecommunications Standards Institute
kRegulatoryDomainAgencyFCC	A2	United States Federal Communications Commission
kRegulatoryDomainAgencyARIB	A3	Japanese Association of Radio Industries and Businesses
kRegulatoryDomainAgencyMIC	A3	Japanese Ministry of Internal Affairs and Communications
kRegulatoryDomainAgencyMKK	A3	Japanese Ministry of Telecommunications
kRegulatoryDomainAgencyTELEC	A3	Japanese Telecommunications Engineering Center
kRegulatoryDomainAgencyKC	A4	Korean Certification
kRegulatoryDomainAgencyNCC	A5	Taiwanese National Communications Commission

Table 2. Agency-specific Regulatory Domain Codes

Mnemonic	Code	Description
kRegulatoryDomainCountryAD	AD	Andorra
kRegulatoryDomainCountryAE	AE	United Arab Emirates
kRegulatoryDomainCountryAF	AF	Afghanistan
kRegulatoryDomainCountryAG	AG	Antigua and Barbuda
kRegulatoryDomainCountryAI	AI	Anguilla
kRegulatoryDomainCountryAL	AL	Albania
kRegulatoryDomainCountryAM	AM	Armenia
kRegulatoryDomainCountryAO	AO	Angola
kRegulatoryDomainCountryAQ	AQ	Antarctica
kRegulatoryDomainCountryAR	AR	Argentina
kRegulatoryDomainCountryAS	AS	American Samoa
kRegulatoryDomainCountryAT	AT	Austria
kRegulatoryDomainCountryAU	AU	Australia
kRegulatoryDomainCountryAW	AW	Aruba
kRegulatoryDomainCountryAX	AX	Åland Islands
kRegulatoryDomainCountryAZ	AZ	Azerbaijan
kRegulatoryDomainCountryBA	BA	Bosnia and Herzegovina
kRegulatoryDomainCountryBB	BB	Barbados
kRegulatoryDomainCountryBD	BD	Bangladesh
kRegulatoryDomainCountryBE	BE	Belgium
kRegulatoryDomainCountryBF	BF	Burkina Faso
kRegulatoryDomainCountryBG	BG	Bulgaria
kRegulatoryDomainCountryBH	BH	Bahrain
kRegulatoryDomainCountryBI	BI	Burundi
kRegulatoryDomainCountryBJ	BJ	Benin
kRegulatoryDomainCountryBL	BL	Saint Barthélemy
kRegulatoryDomainCountryBM	BM	Bermuda
kRegulatoryDomainCountryBN	BN	Brunei Darussalam
kRegulatoryDomainCountryBO	BO	Bolivia
kRegulatoryDomainCountryBQ	BQ	Bonaire, Sint Eustatius and Saba
kRegulatoryDomainCountryBR	BR	Brazil
kRegulatoryDomainCountryBS	BS	Bahamas
kRegulatoryDomainCountryBT	BT	Bhutan
kRegulatoryDomainCountryBV	BV	Bouvet Island
kRegulatoryDomainCountryBW	BW	Botswana
kRegulatoryDomainCountryBY	BY	Belarus
kRegulatoryDomainCountryBZ	BZ	Belize
kRegulatoryDomainCountryCA	CA	Canada
kRegulatoryDomainCountryCC	CC	Cocos Islands
kRegulatoryDomainCountryCD	CD	Congo Democratic Republic
kRegulatoryDomainCountryCF	CF	Central African Republic
kRegulatoryDomainCountryCG	CG	Congo
kRegulatoryDomainCountryCH	CH	Switzerland
kRegulatoryDomainCountryCI	CI	Côte d'Ivoire
kRegulatoryDomainCountryCK	CK	Cook Islands
kRegulatoryDomainCountryCL	CL	Chile
kRegulatoryDomainCountryCM	CM	Cameroon
kRegulatoryDomainCountryCN	CN	China
kRegulatoryDomainCountryCO	CO	Colombia
kRegulatoryDomainCountryCR	CR	Costa Rica
kRegulatoryDomainCountryCU	CU	Cuba
kRegulatoryDomainCountryCV	CV	Cape Verde
kRegulatoryDomainCountryCW	CW	Curaçao
kRegulatoryDomainCountryCX	CY	Cyprus
kRegulatoryDomainCountryCY	CX	Christmas Island
kRegulatoryDomainCountryCZ	CZ	Czech Republic
kRegulatoryDomainCountryDE	DE	Germany
kRegulatoryDomainCountryDJ	DJ	Djibouti
kRegulatoryDomainCountryDK	DK	Denmark
kRegulatoryDomainCountryDM	DM	Dominica
kRegulatoryDomainCountryDO	DO	Dominican Republic
kRegulatoryDomainCountryDZ	DZ	Algeria
kRegulatoryDomainCountryEC	EC	Ecuador
kRegulatoryDomainCountryEE	EE	Estonia
kRegulatoryDomainCountryEG	EG	Egypt
kRegulatoryDomainCountryEH	EH	Western Sahara
kRegulatoryDomainCountryER	ER	Eritrea
kRegulatoryDomainCountryES	ES	Spain
kRegulatoryDomainCountryET	ET	Ethiopia
kRegulatoryDomainCountryFI	FI	Finland
kRegulatoryDomainCountryFJ	FJ	Fiji
kRegulatoryDomainCountryFK	FK	Falkland Islands
kRegulatoryDomainCountryFM	FM	Micronesia
kRegulatoryDomainCountryFO	FO	Faroe Islands
kRegulatoryDomainCountryFR	FR	France
kRegulatoryDomainCountryGA	GA	Gabon
kRegulatoryDomainCountryGB	GB	United Kingdom
kRegulatoryDomainCountryGD	GD	Grenada
kRegulatoryDomainCountryGE	GE	Georgia
kRegulatoryDomainCountryGF	GF	French Guiana
kRegulatoryDomainCountryGG	GG	Guernsey
kRegulatoryDomainCountryGH	GH	Ghana
kRegulatoryDomainCountryGI	GI	Gibraltar
kRegulatoryDomainCountryGL	GL	Greenland
kRegulatoryDomainCountryGM	GM	Gambia
kRegulatoryDomainCountryGN	GN	Guinea
kRegulatoryDomainCountryGP	GP	Guadeloupe
kRegulatoryDomainCountryGQ	GQ	Equatorial Guinea
kRegulatoryDomainCountryGR	GR	Greece
kRegulatoryDomainCountryGS	GS	South Georgia
kRegulatoryDomainCountryGT	GT	Guatemala
kRegulatoryDomainCountryGU	GU	Guam
kRegulatoryDomainCountryGW	GW	Guinea Bissau
kRegulatoryDomainCountryGY	GY	Guyana
kRegulatoryDomainCountryHK	HK	Hong Kong
kRegulatoryDomainCountryHM	HM	Heard and McDonald Islands
kRegulatoryDomainCountryHN	HN	Honduras
kRegulatoryDomainCountryHR	HR	Croatia
kRegulatoryDomainCountryHT	HT	Haiti
kRegulatoryDomainCountryHU	HU	Hungary
kRegulatoryDomainCountryID	ID	Indonesia
kRegulatoryDomainCountryIE	IE	Ireland
kRegulatoryDomainCountryIL	IL	Israel
kRegulatoryDomainCountryIM	IM	Isle of Man
kRegulatoryDomainCountryIN	IN	India
kRegulatoryDomainCountryIO	IO	British Indian Ocean Territory
kRegulatoryDomainCountryIQ	IQ	Iraq
kRegulatoryDomainCountryIR	IR	Iran
kRegulatoryDomainCountryIS	IS	Iceland
kRegulatoryDomainCountryIT	IT	Italy
kRegulatoryDomainCountryJE	JE	Jersey
kRegulatoryDomainCountryJM	JM	Jamaica
kRegulatoryDomainCountryJO	JO	Jordan
kRegulatoryDomainCountryJP	JP	Japan
kRegulatoryDomainCountryKE	KE	Kenya
kRegulatoryDomainCountryKG	KG	Kyrgyzstan
kRegulatoryDomainCountryKH	KH	Cambodia
kRegulatoryDomainCountryKI	KI	Kiribati
kRegulatoryDomainCountryKM	KM	Comoros
kRegulatoryDomainCountryKN	KN	Saint Kitts and Nevis
kRegulatoryDomainCountryKP	KP	North Korea
kRegulatoryDomainCountryKR	KR	South Korea
kRegulatoryDomainCountryKW	KW	Kuwait
kRegulatoryDomainCountryKY	KY	Cayman Islands
kRegulatoryDomainCountryKZ	KZ	Kazakhstan
kRegulatoryDomainCountryLA	LA	Lao
kRegulatoryDomainCountryLB	LB	Lebanon
kRegulatoryDomainCountryLC	LC	Saint Lucia
kRegulatoryDomainCountryLI	LI	Liechtenstein
kRegulatoryDomainCountryLK	LK	Sri Lanka
kRegulatoryDomainCountryLR	LR	Liberia
kRegulatoryDomainCountryLS	LS	Lesotho
kRegulatoryDomainCountryLT	LT	Lithuania
kRegulatoryDomainCountryLU	LU	Luxembourg
kRegulatoryDomainCountryLV	LV	Latvia
kRegulatoryDomainCountryLY	LY	Libya
kRegulatoryDomainCountryMA	MA	Morocco
kRegulatoryDomainCountryMC	MC	Monaco
kRegulatoryDomainCountryMD	MD	Moldova
kRegulatoryDomainCountryME	ME	Montenegro
kRegulatoryDomainCountryMF	MF	Saint Martin
kRegulatoryDomainCountryMG	MG	Madagascar
kRegulatoryDomainCountryMH	MH	Marshall Islands
kRegulatoryDomainCountryMK	MK	Macedonia
kRegulatoryDomainCountryML	ML	Mali
kRegulatoryDomainCountryMM	MM	Myanmar
kRegulatoryDomainCountryMN	MN	Mongolia
kRegulatoryDomainCountryMO	MO	Macao
kRegulatoryDomainCountryMP	MP	Northern Mariana Islands
kRegulatoryDomainCountryMQ	MQ	Martinique
kRegulatoryDomainCountryMR	MR	Mauritania
kRegulatoryDomainCountryMS	MS	Montserrat
kRegulatoryDomainCountryMT	MT	Malta
kRegulatoryDomainCountryMU	MU	Mauritius
kRegulatoryDomainCountryMV	MV	Maldives
kRegulatoryDomainCountryMW	MW	Malawi
kRegulatoryDomainCountryMX	MX	Mexico
kRegulatoryDomainCountryMY	MY	Malaysia
kRegulatoryDomainCountryMZ	MZ	Mozambique
kRegulatoryDomainCountryNA	NA	Namibia
kRegulatoryDomainCountryNC	NC	New Caledonia
kRegulatoryDomainCountryNE	NE	Niger
kRegulatoryDomainCountryNF	NF	Norfolk Island
kRegulatoryDomainCountryNG	NG	Nigeria
kRegulatoryDomainCountryNI	NI	Nicaragua
kRegulatoryDomainCountryNL	NL	Netherlands
kRegulatoryDomainCountryNO	NO	Norway
kRegulatoryDomainCountryNP	NP	Nepal
kRegulatoryDomainCountryNR	NR	Nauru
kRegulatoryDomainCountryNU	NU	Niue
kRegulatoryDomainCountryNZ	NZ	New Zealand
kRegulatoryDomainCountryOM	OM	Oman
kRegulatoryDomainCountryPA	PA	Panama
kRegulatoryDomainCountryPE	PE	Peru
kRegulatoryDomainCountryPF	PF	French Polynesia
kRegulatoryDomainCountryPG	PG	Papua New Guinea
kRegulatoryDomainCountryPH	PH	Philippines
kRegulatoryDomainCountryPK	PK	Pakistan
kRegulatoryDomainCountryPL	PL	Poland
kRegulatoryDomainCountryPM	PM	Saint Pierre and Miquelon
kRegulatoryDomainCountryPN	PN	Pitcairn
kRegulatoryDomainCountryPR	PR	Puerto Rico
kRegulatoryDomainCountryPS	PS	Palestine
kRegulatoryDomainCountryPT	PT	Portugal
kRegulatoryDomainCountryPW	PW	Palau
kRegulatoryDomainCountryPY	PY	Paraguay
kRegulatoryDomainCountryQA	QA	Qatar
kRegulatoryDomainCountryRE	RE	Reunion
kRegulatoryDomainCountryRO	RO	Romania
kRegulatoryDomainCountryRS	RS	Serbia
kRegulatoryDomainCountryRU	RU	Russia
kRegulatoryDomainCountryRW	RW	Rwanda
kRegulatoryDomainCountrySA	SA	Saudi Arabia
kRegulatoryDomainCountrySB	SB	Solomon Islands
kRegulatoryDomainCountrySC	SC	Seychelles
kRegulatoryDomainCountrySD	SD	Sudan
kRegulatoryDomainCountrySE	SE	Sweden
kRegulatoryDomainCountrySG	SG	Singapore
kRegulatoryDomainCountrySH	SH	Saint Helena, Ascension and Tristan da Cunha
kRegulatoryDomainCountrySI	SI	Slovenia
kRegulatoryDomainCountrySJ	SJ	Svalbard and Jan Mayen
kRegulatoryDomainCountrySK	SK	Slovakia
kRegulatoryDomainCountrySL	SL	Sierra Leone
kRegulatoryDomainCountrySM	SM	San Marino
kRegulatoryDomainCountrySN	SN	Senegal
kRegulatoryDomainCountrySO	SO	Somalia
kRegulatoryDomainCountrySR	SR	Suriname
kRegulatoryDomainCountrySS	SS	South Sudan
kRegulatoryDomainCountryST	ST	Sao Tome and Principe
kRegulatoryDomainCountrySV	SV	El Salvador
kRegulatoryDomainCountrySX	SX	Sint Maarten
kRegulatoryDomainCountrySY	SY	Syria
kRegulatoryDomainCountrySZ	SZ	Swaziland
kRegulatoryDomainCountryTC	TC	Turks and Caicos Islands
kRegulatoryDomainCountryTD	TD	Chad
kRegulatoryDomainCountryTF	TF	French Southern Territories
kRegulatoryDomainCountryTG	TG	Togo
kRegulatoryDomainCountryTH	TH	Thailand
kRegulatoryDomainCountryTJ	TJ	Tajikistan
kRegulatoryDomainCountryTK	TK	Tokelau
kRegulatoryDomainCountryTL	TL	Timor-Leste
kRegulatoryDomainCountryTM	TM	Turkmenistan
kRegulatoryDomainCountryTN	TN	Tunisia
kRegulatoryDomainCountryTO	TO	Tonga
kRegulatoryDomainCountryTR	TR	Turkey
kRegulatoryDomainCountryTT	TT	Trinidad and Tobago
kRegulatoryDomainCountryTV	TV	Tuvalu
kRegulatoryDomainCountryTW	TW	Taiwan
kRegulatoryDomainCountryTZ	TZ	Tanzania
kRegulatoryDomainCountryUA	UA	Ukraine
kRegulatoryDomainCountryUG	UG	Uganda
kRegulatoryDomainCountryUM	UM	United States Minor Outlying Islands
kRegulatoryDomainCountryUS	US	United States
kRegulatoryDomainCountryUY	UY	Uruguay
kRegulatoryDomainCountryUZ	UZ	Uzbekistan
kRegulatoryDomainCountryVA	VA	Holy See (Vatican City State)
kRegulatoryDomainCountryVC	VC	Saint Vincent and the Grenadines
kRegulatoryDomainCountryVE	VE	Venezuela
kRegulatoryDomainCountryVG	VG	BritishVirginIslands
kRegulatoryDomainCountryVI	VI	USVirginIslands
kRegulatoryDomainCountryVN	VN	Vietnam
kRegulatoryDomainCountryVU	VU	Vanuatu
kRegulatoryDomainCountryWF	WF	Wallis and Futuna
kRegulatoryDomainCountryWS	WS	Samoa
kRegulatoryDomainCountryYE	YE	Yemen
kRegulatoryDomainCountryYT	YT	Mayotte
kRegulatoryDomainCountryZA	ZA	South Africa
kRegulatoryDomainCountryZM	ZM	Zambia
kRegulatoryDomainCountryZW	ZW	Zimbabwe

Table 3. Country-specific Regulatory Domain Codes

jaylogue commented 4 years ago

A little more background on this: Initially I was in favor of using a trait to control wireless regulatory configuration. However I was recently convinced that this was a more natural fit for the existing Network Provisioning profile, seeing as it has a strong effect on the process of finding and joining a network.

Another minor benefit to this approach is it possible to implement code-constrained devices that have limited or no support for WDM. An example of this might be a temp sensor device that only emits temp samples as multicast-only subscriptionless notifies. Requiring support for WDM view/update for wireless reg control would add a lot of code.

gerickson commented 4 years ago

@jaylogue fully agreed on that sentiment. I believe so long as we have a TLV description that reasonably mirrors, or that can be extended to mirror, what I described above, that should work.

If necessary, this could be surfaced in device-published capability WDM schema in the future; however, I don't see a near-term use case for that.

jaylogue commented 4 years ago

@gerickson : The document you cite largely described how the rule sets are codified, whereas the configuration data specified here is meant as input to the process of selecting among those rule sets. It is not my belief that we need the ability to dynamically configure arbitrary new rule sets on a device. Thus I believe the input data form is correct. But please correct me if I've missed something.

Regarding the use of country codes, versus or in addition to designators for regulatory domains (e.g. A2 for "FCC"), my impression is that there is no standardization for such regulatory domain designators. Because of this, I expect clients to operate in terms of country codes only--e.g. a mobile commissioning device will first determine the country in which it is operating (via geolocation) and then use that to configure the device. I can see how it would be prudent to broaden the input field to allow for designators other than just country codes. But is there a specific case where this is needed?

I agree with using "00" for world-wide, and will update the proposal. I would prefer to continue to use null instead of "??" for unknown.

gerickson commented 4 years ago

I don't disagree with any of the above. The key for me is that whatever the form of the input 'selector', that there be as minimal, mechanistic, and, ideally, 1:1 a mapping or translation as is possible from that input to the rule sets in devices deployed in the field. It seems like we're aligning with that goal.

As for NULL vs "??", NULL is more TLVish and the mapping from NULL to "??" is 1:1, so I'm fine with that.

jaylogue commented 4 years ago

Proposal updated:

Use "00" for world-wide designation
Generalized "operatingCountry" to "regulatoryDomain" to allow for the possibility that the values could, in the future, include designators that aren't countries (e.g. the proposed A2 for FCC). Such values are not allowed now, however.
Eliminated use of abbreviations in protocol definition. (The diagrams still contain them for space reasons).

jaylogue commented 4 years ago

Proposal updated:

Defined numerical values for new status codes.
Clarified use of "unknown" operatingLocation.

jaylogue commented 4 years ago

Proposal updated: Updated TLV definitions for SetWirelessRegulatoryConfigArguments and GetWirelessRegulatoryConfigResults to match the latest Weave TLV schema language syntax.

jaylogue commented 4 years ago

This feature has been completed with the exception of the work needed to extend the Objective-C++ Device Manager API. This latter work is now captured in issue https://github.com/openweave/openweave-core/issues/494

openweave / openweave-core