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. > *Done* > > 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 > >
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
