Hi, Vince. Sorry not to be responding to this until now, but IETF
week got in the way... and we did have a good lunch talk, and dealt
with the most important issues.
Further comments below, only on things that I think need further
comment. For anything you don't see, assume I'm happy with your
response and carry on.
Barry
>> ======================= DISCUSS =======================
>>
>> -- Section 4 --
>>
>> o Device Registration (Section 4.3) MAY be used by the Master Device
>> and MAY be implemented by the Database, either as a separate
>> component or as part of the Available Spectrum Query (Section 4.4)
>> component.
>>
>> I don't think the first MAY is correct. If the database requires
>> registration, it is *not* optional for the Master Device to use it. I
>> think this needs some rework. The same is true with "Device
>> Validation".
>
> Based on comments from our AD, we wanted to separate requirements for the
> protocol itself from database-specific and regulatory-domain requirements.
> Thus, from the protocol's perspective, it's a MAY.
I understand the desire, but I disagree with how you're trying to
separate it. From a protocol perspective I absolutely think it's not
a MAY: when it's required, it's required... so under some conditions
it's optional -- or perhaps even disallowed -- and under others it's
required (the protocol doesn't work if you don't do it).
> Having said that, the text can be clarified a bit. Suggestion:
>
> o Device Registration (Section 4.4) MAY be used by the Master Device
> and MAY be implemented by the Database. When implementing Device
> Registration, the Database MAY implement it either as a separate
> component or as part of the Available Spectrum Query (Section 4.5)
> component.
I don't think this helps. But see below.
Below is here.
I think that part of the problem is in trying to stuff 2119 key words
in where they don't really fit. This list is one of those places. So
let me make the suggestion that you take out the 2119 key words from
here, and instead talk about what the implementation and use
requirements are in understandable plain English. I'll take a stab at
it, to show what I mean:
o Database Discovery (Section 4.1) is a required component for
the Master Device.
o Initialization (Section 4.2) is a required component for the
Master Device and the Database. It is used by the Master Device
when certain necessary information has not been preconfigured.
o Device Registration (Section 4.3) is a required component for
the Master Device and an optional component for the Database.
It can be implemented as a separate component, or as part of the
Available Spectrum Query (Section 4.4) component. It is used by
the Master Device when the Database requires it.
o Available Spectrum Query (Section 4.4) is a required component
for the Master Device and the Database.
o Spectrum Use Notify (Section 4.4.5) is an optional component for
the Master Device and a required component for the Database. Its
use by the Master Device is optional; if it is used, the Database
is required to accept it.
o Device Validation (Section 4.5) is a required component for the
Master Device and an optional component for the Database. It is
used by the Master Device when the Database requires it.
Of course, check that I got those right, and play with them as needed.
You certainly could make all the "required" and "optional" into
"REQUIRED" and "OPTIONAL", but I don't think it would be doing anyone
a service, honestly. See what Pete thinks about this, as you've
obviously discussed this bit with Pete before.
>> -- Section 4.3.2 --
>>
>> If the Database accepts the
>> registration for none of the rulesets it supports, the Database MUST
>> return the NOT_REGISTERED error (See Error Codes (Section 5.17)).
>>
>> I can't follow this sentence at all. Do you mean, "If the Database
>> does not accept the registration for any of the rulesets" ? Or do you
>> mean something else? Can you re-word this, please?
>
> Heh, I was afraid "any" is ambiguous.
>
> "If the Database does not accept the registration for any of the rulesets":
>
> - Does that mean if, out of 3, one was not acceptable, it passes the "any"
> test?
> - Or does that mean "none of them"
>
> Hence...the attempt at being more precise by using "none".
Ahhhhhhh. I see. I hadn't read it that way.
Glrf.
How about this, then?:
NEW
If the Database fails to accept the
registration for all of the rulesets it supports, the Database MUST
return the NOT_REGISTERED error (See Error Codes (Section 5.17)).
END
>> -- Section 6 --
>> How is the reference to JSON Schema [I-D.zyp-json-schema] not
>> normative, when the 6.x subsections quite depend upon the
>> understanding of the schema format that it describes?
>>
>> I see that the Gen-ART review mentioned this also, but the response is
>> quite troubling. No, the mechanism you're using is not sufficiently
>> self explanatory. I understand it -- I do -- but I had to figure it
>> out (I decided not to go look at the Zyp draft), and we can't assume
>> that arbitrary implementors will get it right. We need a well defined
>> way to explain how JSON objects are constructed. And, unfortunately,
>> the JSON working group chose *not* to take on a work item for this
>> (which I was pushing for).
>>
>> We have at least three proposals (apart from Zyp, there's Newton
>> (draft-newton-json-content-rules), and there's the mechanism that I
>> proposed, which is used in Section 6.2 of RFC 7071), but nothing
>> that's being taken forward as a standard yet.
>
> I guess the 3rd option is to just describe by example. Hopefully we can
> discuss this at the F2F.
And we did, and we've decided to go with description by example. This
point is settled -- modulo, of course, seeing the result, but I have
every confidence.
>> The second paragraph and the list is fine, and the third is mostly OK,
>> except for the URI. You'll need to ask IANA how they want to receive
>> requests (by email or through a web URI), and specify that in
>> paragraph 3 instead of what's there now.
>
> FYI. From http://www.iana.org, you can navigate to a "Protocol Registration
> Forms" page to submit requests for new assignments.
Right... I was suggesting that you need to sort things out with IANA
to make sure you have a form, and work out with IANA the best way to
refer to the form here. It might be best to have a URI for the form
directly, if IANA thinks it will be persistent. Or perhaps some other
advice will be better. But it's probably not best to just tell people
to go to the main IANA page, and expect them to click around and find
it themselves.
> Thanks. Proposed text:
>
> All registries use the Specification Required policy [RFC5226], with
> a Designated Expert appointed by the IESG. Specific criteria that
> the Designated Expert should use in assessing registrations are given
> below in the description of each registry. The Designated Expert
> should take advice from the community through the [email protected]
> mailing list, and the registrant is encouraged to post to the mailing
> list before formally requesting the registration from IANA. The
> intention is that new registrations will be accompanied by a
> published specification. But in order to allow for the allocation of
> values prior to publication of the specification, the Designated
> Expert can approve allocations once it seems clear that the
> specification will be published.
>
> Is the last part (about allocation before publication of spec) also process
> that should be omitted? Or are they instructions to the DE?
I think that text is fine, and, yes, saying that the DE can approve
early allocations is fine -- not all registries are suitable for that.
>> ======================= COMMENT -- substantive =======================
>>
>> General:
>> You appear to sometimes use "parameter" to refer to a structure (such
>> as GeoLocation) and also the fields within the parameter (see Section
>> 5.1, for example). I find this confusing, and suggest that you do not
>> use the same term for both.
>
> You're right. Perhaps, when referring to a structure, I should use "object"
> in the JSON sense?
I think we've settled on "structure" for this, so this one's done also.
>> Hm, it seems that steps 5 and 7 are actually explained in the
>> paragraph after the numbered steps. So do they really belong in the
>> numbered steps at all?
>
> The numbered steps are supposed to correspond to the order in which these
> steps happen, so I think it's important to leave them there.
Indeed, and your re-wording of the various steps looks good to me; thanks.
>> ======================= COMMENT -- minor =======================
All OK in this section
>> ==============================================
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
