Hi Lada, Thanks for the review. As you rightfully noticed:
> The ietf-bgp-communities module represents an interesting use case > where YANG is used outside of its standard server-client domain for > publishing information about configured BGP communities. YANG > essentially plays a role of a (JSON) schema language. The companion question is whether following RFC8791 makes more sense here or keep the current design. How do you feel about this? Cheers, Med > -----Message d'origine----- > De : Ladislav Lhotka via Datatracker <[email protected]> > Envoyé : mercredi 21 mai 2025 11:46 > À : [email protected] > Cc : [email protected]; > [email protected] > Objet : draft-ietf-grow-yang-bgp-communities-04 early Yangdoctors > review > > > Document: draft-ietf-grow-yang-bgp-communities > Title: A YANG Data Model for BGP Communities > Reviewer: Ladislav Lhotka > Review result: Ready with Nits > > The ietf-bgp-communities module represents an interesting use case > where YANG is used outside of its standard server-client domain for > publishing information about configured BGP communities. YANG > essentially plays a role of a (JSON) schema language. > > **** General comments > > - Section 6 (Data Elements) contains a hierarchy of subsections, > one for each data node of the schema tree. These subsections > (i) repeat information that is formally specified in the YANG > module, and (ii) sometimes add extra explanations. Unless there is > a good reason for having this section in the document, I'd suggest > to remove it. Duplicated information invites troubles if this > section and the YANG module get out of sync, and the extra > information, if it is substantial, should be added to descriptions > in the YANG module. > > - Running code seems to exist, which is always good, and the > document refers to two autonomous systems that already use the > schema defined in the YANG module (well, almost, see below). In > both cases, only an entire read-only JSON file can be retrieved > from an URL. I think it might be useful to consider a more granular > service, e.g. using a RESTCONF server, and perhaps even a > possibility of remote edits. > > **** Specific comments > > - The two examples of BGP community data published by AS197000 and > AS25152 are based on an old revision of the YANG module – words in > multi-word identifiers, such as "email-address" are now separated > by a hyphen. Both JSON files also contain other trivial errors: > > * namespace identifiers should be "ietf-bgp-communities" rather > than > "draft-ietf-grow-yang-bgp-communities", see RFC 7951 > > * lists "contacts" and "fields" shoud in fact be "contact" an > "field". > > - At several places, regular expressions are used for specifying > the set of permitted Unicode characters. For example, the > definition of "community-description" typedef contains the > following statement: > > pattern '[^\p{C}]+'; > > I am not sure that this matches the intent – are parsers expected > to handle > combining and extender characters? If so, a positive definition > using the > "\c" character class (XML 1.0 name characters) might be > preferable. > > - Section 8.1 instructs operators to order overlapping community > definitions from most to least preferred. Shouldn't then the > "regular", "extended" and "large" lists be defined as "ordered-by > user"? Alternatively, a "preference" > leaf could be added to make this explicit. > > - In Appendix A, it would be useful to provide an example of > extended community definition. > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
