[Resent because I forgot to Cc everyone.]
On Aug 22, 2014, at 3:03 AM, Vincent Chen <[email protected]> wrote:
>> It should not occur in practice for well-behaved devices.
>>
>> When it is preconfigured, there must be a preconfigured value for each
>> ruleset.
>> Of course, a device may choose to use preconfigured values for only a subset
>> of the rulesets it supports.
>>
>> Note that, in practice, a device needs to be certified for each "ruleset" by
>> whatever process is defined by each applicable regulatory body, so that
>> any preconfigured values will be certified to be compliant.
>
> If this is how it works, shouldn't the document say so? Or was that in the
> requirements document? I admit it's been a while since I read it. :)
>
> I'll clarify the text some. Note, however, that INIT_RESP return these values
> as part of a RulesetInfo structure, so that it is implied that
> preconfiguration also
> must be on a per-ruleset basis.
To be clear, what I was suggesting ought to be documented is that the
information has to be preconfigured and certified by the regulatory authority.
If this is already mentioned in the requirements document, there's no need to
mention it here, although a reference to the previous document might be helpful
for neophytes like me. I don't really know what the mental context of a
reader of this document would be, so please forgive me if I'm being ridiculous
here.
>> In 4.4.2, I think that if none of the rulesets are accepted, the intent
>> is that the database should return a REGISTRATION_RESP with the error
>> element, and will not return a rulesetInfos list. However, the
>> specification does not make an exception for this case when it says "A
>> RulesetInfo list MUST be included" and "The list MUST contain at least
>> one entry". I can't think of another valid interpretation, but you've
>> stated a MUST, so you need to say that it doesn't apply in the case of
>> the error.
>>
>> Ah, right. There is language from INIT_RESP that needs to be repeated here.
>>
>> If the Database does not support the device or any of the rulesets
>> specified in the DeviceDescriptor, it MUST instead return an error
>> with the UNSUPPORTED (Table 1) code in the error response.
>
> That doesn't fix it, though—you need to fix the other MUST to say "unless
> there's an error" or words to that effect.
>
> Actually, REGISTRATION_RESP is returned only when there is not error,
> so if it is returned, it must have one or more entries.
>
> The "it MUST instead return an error" should suffice to clarify this?
The problem I have with this text actually stems from the first paragraph of
the section:
The registration response message acknowledges successful
registration by including a RulesetInfo message for each ruleset in
which the registration is accepted. If the Database does not accept
the registration for any of the rulesets it supports, the Database
MUST return the NOT_REGISTERED error (See Error Codes
(Section 5.17)).
In reviewing this just now, I realized that I may have completely
misinterpreted the second sentence. It probably means either:
If the database does not accept the registration for any single
ruleset it supports, the database MUST return the NOT_REGISTERED
error.
Or:
If none of the rulesets being registered are accepted by the
database, the database MUST return the NOT_REGISTERED error.
Right now, your use of "any" could be interpreted either way.
And then, what I was asking you to change in this DISCUSS item was this:
rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in
the response. Each entry corresponds to a ruleset for which the
registration was accepted. The list MUST contain at least one
entry. [If an error is being returned, this list MUST be
omitted.]
The text in brackets is what I am proposing that you should add. Otherwise
you are giving the implementor conflicting instructions--a MUST is a MUST, and
has to be followed, but of course it can't be followed if no rulesets match.
I'm just asking you to make that explicit so that nobody gets confused.
Anyway, it sounds like we're converging. Let me know if what I'm saying still
doesn't make sense.
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
