Hi Lada,
Did you tag parts that you think are netconf-specific? Identifying those would
help Martin.
I'm asking this because there is even no mention of netconf/restconf in the doc.
Thank you.
Cheers,
Med (as GROW AD)
PS: I have my own opinion on structure extension, as a contributor.
> -----Message d'origine-----
> De : Ladislav Lhotka <[email protected]>
> Envoyé : jeudi 22 mai 2025 09:48
> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>;
> [email protected]
> Cc : [email protected];
> [email protected]
> Objet : RE: draft-ietf-grow-yang-bgp-communities-04 early
> Yangdoctors review
>
>
> Hi Med,
>
> [email protected] writes:
>
> > 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?
>
> I think it can stay as it is. As I wrote in the review, it is IMO
> perfectly possible that the BGP community data might eventually be
> available from a RESTCONF server.
>
> Actually, I am not a fan of the structure extension. It would be
> much cleaner to restructure YANG definition and move the NETCONF-
> specific parts to a separate document. A specification that defines
> YANG as a multi-representation schema language would also make it
> much more accessible to potential users of YANG outside of the
> NETCONF domain - as it is in the present case.
>
> Lada
>
> >
> > 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.
>
> --
> Ladislav Lhotka <[email protected]>
> PGP Key ID: 0xB8F92B08A9F76C67
____________________________________________________________________________________________________________
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]
