Type <Serial> is string, should it be enum?

[matje]

Yuri:

Perhaps Serial should not be defined as a string but rather a type that has one of the above values.

[jelu]

I do not know if this should be so very strict, maybe it should just be a string and it is up to the implementation what kind of serials they support. The list of serials we have today in OpenDNSSEC could just be examples.

[matje]

I would like to ensure that when using the datecounter serial for example, that everybody implements the same behavior.

[jelu]

I don't feel like the behavior of things should be describe in this document, this is only to have a common data structure. Is the behavior described in another draft/RFC/BCP which we can point to and recommend?

[matje]

I think we should couple behavior to the elements: So that if a policy is used in multiple signers (from different code bases) the same behavior set forth by the policy can be expected.

[jelu]

Sure, I just don't want it forced and strict. I think it should be loose and extendable. Also, if the behavior is define elsewhere then we should refer to it and not redefine it.

[matje]

In principle I agree. However in practice it is hard to specify behavior loosely, as you allow for ambiguous interpretations. Perhaps a discussion for the wg.

[jelu]

I did not mean to loosly define behavior, what I think is:

• the Serial leaf should not be constrained to a list of ways to handle the serial.
• we should include a list of recommended ways to handle the serial.
• we should point to other work that has already described the behavior of managing the serial if any such work has already been done (less work for us) otherwise we may as well define that behavior.

[matje]

• Indeed not constrained, but the ones we do define need to be defined well.
• Sure, that can be the ones already used by OpenDNSSEC
• Agree, but the reference must be trustworthy. We can't reference to our wiki page for example.