Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-12.txt

From: Pete Resnick <[email-masked]>
Date: Sun, 22 Jun 2014 13:10:58 -0700

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

---

From: Vincent Chen <[email-masked]>
Date: Mon, 23 Jun 2014 08:02:41 +0800

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-masked]>
wrote:

> the Last Call, but there are still some outstanding issues. I think these
> can be handled during Last Call:
>
> 3.1
>
> anywhere? Are they UTF-8? If I'm writing an implementation, how do I know
> what these are?
>
> contain UTF-8" or be completely opaque and therefore strike commentary on
> the format.
>
> 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.]"
>
> Designated Expert should use in assessing registrations are given below in
> the description of each registry."
>
>
> 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:
>
> 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.
>
> --

-- 
-vince