Paul Wouters <p...@nohats.ca> writes:

> On Tue, 27 Nov 2018, Petr Špaček wrote:
>
>>> MB     7     a mailbox domain name (EXPERIMENTAL)     [RFC1035] MG    
>>> 8     a mail group member (EXPERIMENTAL)     [RFC1035] MR     9     a
>>> mail rename domain name (EXPERIMENTAL)     [RFC1035]
>>
>>
>> Is there any *technical* use for this field? Do we need it in the YANG
>> model?
>
> The technical reason would be "It's dead Jim! Don't bother implementing this"
>
> But if people pick up the yang model and it has all these obsolete
> entries, those people in turn will start some basic implementation /
> support of these. So I understand yang is not the group that should

They should not, if they follow RFC 7950:

   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

But again, the question is whether OBSOLETE in IANA registries means the
same thing.

> make this decision, hence my thought of quickly adding a column to the
> registry to obsolete/deprecate so that yang can skip these.
>
>> Maybe we can just omit it while transforming the registry into model and
>> be done with it ...
>
> But then people think the yang model is incomplete?

Yes, I think it is important to keep the 1-1 mapping between the
registry and YANG module.

Enums tagged as obsolete should be no problem for implementors of the
module, and clients of management protocols such as NETCONF cannot
expect anything else from the server than an error, if they use such an
enum value.

Lada

>
> Paul
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to