> -----Original Message-----
> From: netmod <[email protected]> On Behalf Of Juergen Schoenwaelder
> Sent: 24 February 2021 20:39
> To: [email protected]
> Subject: Re: [netmod] type equivalence
>
> Here is an attempt to come up with better wording. If people agree on
> a new wording, I volunteer to submit an errata.
>
> OLD
>
> o A "type" statement may be replaced with another "type" statement
> that does not change the syntax or semantics of the type. For
> example, an inline type definition may be replaced with a typedef,
> but an int8 type cannot be replaced by an int16, since the syntax
> would change.
>
> NEW
>
> o A "type" statement may be replaced with another "type" statement
> that does not change the semantics of the type or the underlying
> built-in type. For example, an inline type definition may be
> replaced with a semantically equivalent typedef derived from the
> same built-in type, but an int8 type cannot be replaced by an
> int16, since the underlying built-in type would change.
[RW]
Would the text be more clear it is just specified what is allowed, e.g.,
o A "type" statement may be replaced with another "type" statement
that resolves to the same underlying built-in type. For example,
...
What does "semantics of the type" cover?
If I have this type:
typedef "timestamp" {
type "string";
description
"The time of day that an event occurred, in any format";
}
then can I replace it with this definition:
typedef "timestamp" {
type "string";
description
"The time of day, and optionally date, that an event
occurred, in any format";
}
Tangentially, it is worth noting the RFC 8342 also writes about syntactic
constraints covering types:
5.3. The Operational State Datastore (<operational>)
Syntactic constraints MUST NOT be violated, including hierarchical
organization, identifiers, and type-based constraints. If a node in
<operational> does not meet the syntactic constraints, then it
MUST NOT be returned, and some other mechanism should be used to flag
the error.
I'm not sure how clear RFC 8342 section 5.3 is about returning values
that can be represented by the underlying built-in-type, but are outside
the value space defined by a range, length, or pattern statement.
My memory during the discussions was that it is allowed to return a value
outside arange, length, pattern statement, as long as it is contained
in the value space of the built-in-type. E.g., cannot return 257 in a
uint8, but can return 11 even if the type range is 1..10.
But, I'm not sure that is what the text actually states.
Regards,
Rob
>
> /js
>
> On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann wrote:
> > On 2021-02-22, at 15:17, Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> university.de> wrote:
> > >
> > > I guess considering the built-in types as incompatible is the most
> > > robust approach. If we agree that RFC 7950 tried to say this, we could
> > > file an errata and propose clearer language.
> >
> > Right. And we can keep the COMI key-to-URL mapping as is, as this
> clarification is necessary for its correct functioning.
> >
> > Grüße, Carsten
> >
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
