Pete, Again, thanks for the comments.
I am out of town this week, so hope to get the edits in next week. -vince On Mon, Jun 23, 2014 at 4:10 AM, 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". > > 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? > > 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. > > 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. > > 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. > > 8.3: s/MAY be defined/can be defined > > 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.]" > > s/responsible IESG area director should/the IESG shall > > That's automatic, but you can say it as above. > > 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. > > 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." > > > 9.1: s/regulatory rules/regulatory domain > > 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 > > 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. > > 9.1.2.1/9.1.2.2: s/REQUIRED/required and s/OPTIONAL/optional > > 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. > > 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 > > 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. > > 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. > > -- > 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
