RE: Fwd: New Version Notification for draft-troan-6man-universal-ra-option-03.txt

[Vasilenko Eduard <[e-mail]>]

+1 on semantics
The progress on SDN and automation in general is so miserable because it has been discovered that everybody is using different YANG model, and number of YANG models is already 600+.
Therefore, this draft would be useless without strict data model attached.

I have 1 additional comment on syntax:
The world has moved from hard-coded SNMP to flexible (and human-readable) Netcong/YANG. Many other examples exist from management domain. Hence, it looks like the trend.
But where it should stop?
Low level data plane details should definitely stay TLV – XML parsing in ASIC is overkill.
We are talking here about control plane protocol that typically has TLV format for all data.
I did not hear (my problem) that BGP or ISIS have intention to move out of TLV format to something human readable and flexible as XML.
Why? Probably performance problem. Parsing is more resource-consuming.
Will all other control plane protocols migrate to XML in the future? It is an open question.
I am just trying to understand why ND should be the 1st on this path. ISIS and BGP is not supposed to operate in IoT, but ND should.
Is anybody aware about any other control plane protocol that has started migration to XML-like?

Eduard
From: ipv6 [mailto:[e-mail]] On Behalf Of Lorenzo Colitti
Sent: 7 октября 2020 г. 16:38
To: Philip Homburg <[e-mail]>
Cc: IETF IPv6 Mailing List <[e-mail]>
Subject: Re: Fwd: New Version Notification for draft-troan-6man-universal-ra-option-03.txt

On Wed, Oct 7, 2020 at 9:47 PM Philip Homburg <[e-mail]<mailto:[e-mail]>> wrote:
A new RA (or DHCP) option has two aspects: syntax and semantics. What this
draft does is introduce a more complex low level syntax for RA and DHCP
options. I.e., the relatively simple, fixed length fields in RA and DHCP
options are replaced with a generic, compressed, self-describing format.
[...]
Beyond that, encoding options in CBOR does nothing for the semantics of
an option. And it seems to me that most of the discussion is regarding
semantics.

+1. Defining an RA (or DHCP, or whatever) option is not just about defining the syntax. That's actually the easy part. It's about defining the semantics of the option, and what behaviour should occur in response by hosts and routers. The reasons this is important are the same reasons we have all standards: interoperability, vendor independence, ability to engineer networks based on expected behaviour instead of building them empirically around implementation behaviour, etc.