On Mon, Nov 5, 2018 at 9:01 AM Ladislav Lhotka <[email protected]> wrote:
> On Mon, 2018-11-05 at 14:44 +0100, Normen Kowalewski wrote: > > Hi Bob, > > > > > > > On 12. Oct 2018, at 15:48, Bob Harold <[email protected]> wrote: > > > > sorry for the very late reply; please allow two cents inline > > > > > In entries like: > > > > > > enum NSAP-PTR { > > > value "23"; > > > description > > > "Domain name pointer, NSAP style."; > > > reference > > > "- RFC 1348: DNS NSAP RRs > > > > > > - RFC 1637: DNS NSAP Resource Records > > > > > > - RFC 1706: DNS NSAP Resource Records"; > > > } > > > It seems odd to me to create the reference field as a string that > > > contains what looks like YAML, except that it has extra blank > > > lines. > > > > > > > Does YANG not have a standard way to represent a list, and should > > > the reference field always be a list, for consistency? > > > > Listing and enumerating stuff is AFAIK quite at the core of YANG, so it > could > > have been define as something like “reference-list”, if folks focus had > been > > programatic use. > > Yet the respective chapter YANG RFC 6020 section-7.19.4, updated in YANG > 1.1 > > RFC 7950. section-7.21.4, says: > > > > The "reference" statement takes as an argument a string that is a > > human-readable cross-reference to an external document > > > > If we look at the content in the IANA “reference” field today, in the > table at > > > https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 > > it seems that it is quite varied: > > > > * one of more comma seperated RFC numbers > > * name of an internet draft in edgy brackets, > > * a footnote number in edgy brackets > > * a name reference of an author > > * a name reference of some underlying additional document > > * a URL of some underlying additional document > > * the IANA reservation statement, aka [IANA-Reserved] > > as well as > > * combinations of some of the before listed, assumedly with some implicit > > hierarchy of records where such combinations are used. > > > > For this YANG draft, I don’t see a need to normalise types and structure > > within this content beyond what is at IANA today. TO me its OK to just > > reference the IANA content "as is” and formally maintain the YANG > declaration > > in "reference” as "human targeted”. > > > > > > > Also, the "template" and "registration date" fields appear to be > missing. > > > > Do you see a need to replicate all the data fields of this IANA registry > in > > the YANG model, and if yes, what benefit at the YANG end could this add? > > This is my question, too. The "description" and "reference" strings make > sense > in the YANG module as human-readable documentation, and some user > interfaces > also use them as context-sensitive help messages. In contrast, I don't see > any > use for "template" and "registration date" - this is metadata intended for > IANA > internal use only. > > The YANG module isn't going to replace the IANA registry, so it is not > necessary > to replicate everything. > > Lada > > > > > > > Best Regards, > > > > Normen Kowalewski > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > Thanks for considering my questions and responding. It sounds like there are reasons for the way it is, so apparently no changes are required. -- Bob Harold
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
