Hi Martin,
Thank you for the follow-up. The changes look good.
Some easy-to-fix comments for -02:
* s/ietf-grow-yang-bgp-communities/ietf-yang-bgp-communities: we don't include
the WG name in the modules names.
* Given that you don't use any normative text in the core module, remove this
text from the module:
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
* Consider adding reference statements for almost all your typedefs. For
example, as you have many typedefs with patterns, please consider adding a
reference statement with an authoritative source where that pattern is defined
(if any).
* Please fix "urn:ietf:params:xml:ns:yang:ietf-grow-yang-bgpcommunities"
(bgpcommunities should be bgp-communities)
* Add an empty line right after "NOTE: '\' line wrapping per [RFC8792]" in A.1.
This is to be consistent with this part from 8792:
==
7.1.1. Header
The header is two lines long.
The first line is the following 36-character string; this string MAY
be surrounded by any number of printable characters. This first line
cannot itself be folded.
NOTE: '\' line wrapping per RFC 8792
The second line is an empty line, containing only the end-of-line
character sequence. This line provides visual separation for
readability.
==
Cheers,
Med
> -----Message d'origine-----
> De : Martin Pels <mp...@ripe.net>
> Envoyé : dimanche 16 février 2025 15:14
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>;
> grow@ietf.org
> Objet : Re: [GROW] Review of draft-ietf-grow-yang-bgp-
> communities-02
>
>
> Hi Med,
>
> Thank you for your thorough review of the draft and the model. I
> just published a version 03 which incorporates your changes and
> suggestions.
> I'm addressing the questions you have about the model below. I
> have also read the YANG authors guidance and made a few
> additional improvements based on this.
>
> An early yangdoctors review seems like a sensible approach.
>
> Chairs, could you initiate such a review? Please specifically
> mention the question whether using the base yang or yang-sx would
> be appropriate for this model.
>
> To answer the questions from the review:
>
> > asn/asn4: Is this really needed given than both forms are
> covered by > as-number
>
> Depending on which type of Extended Community[0] is defined, the
> allowed content of the Global Administrator field is different.
> For example, an Extended Community of type 0 (Transitive Two-
> Octet AS-Specific) may not contain a four-octet ASN. This is why
> the model specifies the two options with different types. I have
> added constraints to the model to make this more explicit.
>
> Furthermore, future augmentations of the model may specify IPv4-
> Address-Specific communities or other forms. For these, "inet:as-
> number" cannot be used either.
>
> > length: What is the expected use of this?
>
> Within the model, a Local Administrator or Local Data Part may be
> subdivided into multiple fields. See example 2 in the appendix
> for an example of this. A parser needs to be aware of the length
> of each of these sub-fields to know how many decimals or bits to
> match on. I have added some text to the draft to clarify this.
>
> I hope this addresses all of your points.
>
> Kind regards,
> Martin
>
> [0]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.iana.org%2Fassignments%2Fbgp-extended-communities%2Fbgp-
> extended-
> communities.xhtml&data=05%7C02%7Cmohamed.boucadair%40orange.com%7
> Cc01653bf01eb41ac08bc08dd4e942eb7%7C90c7a20af34b40bfbc48b9253b6f5
> d20%7C0%7C0%7C638753120540867360%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0
> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6h5qa9nRW50cPHcK7hlYdbOPc3
> OZgCRvd0bNyIubMF4%3D&reserved=0
>
>
____________________________________________________________________________________________________________
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 -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org
