On Thu, Jul 3, 2014 at 8:38 PM, Vincent Chen <[email protected]> wrote:
> Pete, > > Thanks for the suggestions. They seem reasonable except for some of the > comments for the IANA Sections 9.1.x.x and 9.2.x.x. These registries are > for extending the protocol, so should contain protocol-style language. > Please see in-line comments below. > > Thanks. > > -vince > > > On Sun, Jun 22, 2014 at 1:10 PM, Pete Resnick <[email protected]> > wrote: > >> I've sat on this document for far too long. I've sent in the request for >> the Last Call, but there are still some outstanding issues. I think these >> can be handled during Last Call: >> >> 3.1 >> >> NOTE: Regulatory rules contain many device-only requirements that >> govern device behavior, independent of any database rules. These >> requirements may be complex and involve device behavior that are not >> easily parameterized. The ruleset-id parameter provides a mechanism >> for the Database to inform the Master Device of the applicable >> ruleset without having to express device-side behavior within the >> protocol. The ruleset identifier is a string value that contains the >> name of the regulatory body that established the rules and version >> information, such as "FccTvBandWhiteSpace-2010". >> >> No change got made to this paragraph between -11 and -12, even though it >> still refers to "regulatory rules". Might I suggest: >> >> NOTE: Some regulatory domains specify sets of requirements for device >> behavior that may be complex and not easily parameterized. The >> ruleset-id parameter provides a mechanism for the Database to inform >> the Master Device of an applicable ruleset, and for devices with >> out-of-band knowledge of the particular regulatory domain >> requirements to satisfy those requirements, without having to specify >> the device-side behavior within the protocol. Ruleset identifiers >> will normally contain the name of the regulatory body that >> established the rules and version information, such as >> "FccTvBandWhiteSpace-2010". >> > > *Done* > > >> >> 5.2: Are the formats of serialNumber, manufacturerId, modelId defined >> anywhere? Are they UTF-8? If I'm writing an implementation, how do I know >> what these are? >> > > *Done. Specified UTF-8.* > > >> 5.8 "It MAY contain UTF-8". That's not interoperable. It either "MUST >> contain UTF-8" or be completely opaque and therefore strike commentary on >> the format. >> > > *Done. MUST be UTF-8* > > >> >> 5.16/5.17 "MAY be in any language and contain UTF-8 characters". First, >> separate out "MAY be in any language" from the format. But as for the >> format, again, that's not interoperable. In this case, I think "MUST be >> UTF-8" is the only real choice. >> > > *Done* > > >> >> 8.1: >> >> s/they MUST be registered/they are registered >> s/64 characters/64 octets >> >> The octets/characters thing doesn't make a difference here, but >> consistency is always a fine thing. >> > > *Done* > > >> >> 8.3: s/MAY be defined/can be defined >> > > *Done* > > >> >> 9: >> >> Insert at the top: "[RFC Editor/IANA: Please replace "[[ this document >> ]]" with the RFC number of this document as indicated below, and remove >> this note prior to publication.]" >> > > *Done* > > >> >> s/responsible IESG area director should/the IESG shall >> >> That's automatic, but you can say it as above. >> > > *Done* > >> >> s/30 days/2 weeks >> >> Let's make it a normal Last Call length. I think that will make the >> logistics work a bit better. >> > > *Done* > >> >> Also, add on to the end of that paragraph: "Specific criteria that the >> Designated Expert should use in assessing registrations are given below in >> the description of each registry." >> > > *Done* > >> >> >> 9.1: s/regulatory rules/regulatory domain >> > > *Done* > >> >> 9.1.1: >> >> OLD >> Ruleset name: The name of the ruleset. It is a string value that >> contains the name of the regulatory body that established the >> rules and version information. The length of the string MUST NOT >> exceed 64 US-ASCII characters. >> NEW >> Ruleset identifier: The name of the ruleset. See [[ this document ]], >> Section 8.1 for the format requirements of this identifier. >> >> s/New parameters MUST be/New parameters are >> > > *Done* > >> >> 9.1.2: >> >> OLD >> as of this writing, it is the only regulatory >> domain that has finalized rules. There is no intent to restrict the >> protocol to FCC rules. >> NEW >> as of this writing, they are the only regulatory >> domains that have finalized rules. There is no intent to restrict the >> protocol to FCC or ETSI rules. >> > > *Done* > > >> >> 9.1.2.1/9.1.2.2: s/REQUIRED/required and s/OPTIONAL/optional >> > > *These sections describe protocol extensions needed for each ruleset, so > the REQUIRED and OPTIONAL are protocol requirements, I believe. * > * E.g., if the ruleset is "FccTvBandWhiteSpace-2010", then "fccId" is > REQUIRED....at the protocol level.* > > >> 9.1.1.1: In the DeviceOwner definition, I suggest changing "MUST >> contain" to "is mandated to contain" (3 times), to make it clear that this >> is a regulatory requirement, not a protocol requirement. >> > > > *Actually, this is also a protocol requirement. The regulatory domain does > not require any specific encoding for the owner information.* > > >> >> 9.1.2.2: >> >> s/MUST NOT exceed 64 octets/See [[ this document ]], Section 5.2 >> s/MUST respond/is mandated to respond >> s/MUST set this/is mandated to set this >> > > *Done* > >> >> 9.2.2.1: >> >> ...MUST NOT exceed 32 US-ASCII characters... >> >> If that's a protocol requirement, it belongs in section 5.2. It doesn't >> belong here. >> > > *Since this is a new parameter for extending the protocol, I believe it is > a protocol requirement. There would be no place to put this in section 5.2, > since the parameter does not exist in the base protocol.* > > > >> >> 9.2.2.5 >> >> The string value MUST NOT exceed 64 octets in length. >> >> Is that an ETSI requirement? Then rewrite as "The ETSI standard specifies >> that the string value be a maximum of 64 octets in length." Otherwise, >> strike the sentence. > > > *Again. This is a new parameter, so I believe it is a protocol > requirement. The ETSI standard actually does not contain any language to > limit the number of characters. This was determined by consulting w/ > Cesar Gutierrez of Ofcom.* > > >> >> -- >> Pete Resnick<http://www.qualcomm.com/~presnick/> >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
