thanks for the explanation, Paul
Sent from my iPhone > On Jan 22, 2025, at 01:32, mohamed.boucad...@orange.com wrote: > > Hi Paul, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Paul Wouters via Datatracker <nore...@ietf.org> >> Envoyé : mardi 21 janvier 2025 21:52 >> À : The IESG <i...@ietf.org> >> Cc : draft-ietf-opsawg-teas-common...@ietf.org; opsawg- >> cha...@ietf.org; opsawg@ietf.org; rro...@ciena.com; >> rro...@ciena.com >> Objet : Paul Wouters' No Objection on draft-ietf-opsawg-teas- >> common-ac-14: (with COMMENT) >> >> >> Paul Wouters has entered the following ballot position for >> draft-ietf-opsawg-teas-common-ac-14: No Objection >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free >> to cut this introductory paragraph, however.) >> >> >> ----------------------------------------------------------------- >> COMMENT: >> ----------------------------------------------------------------- >> >> One minor comment / question: >> >> Why the groupings split on addr family split, eg ipv4-static-rtg- >> entry and ipv6-static-rtg-entry ? >> This causes a lot of almost identical duplication ? Couldn't the >> values just take (v4 or v6) ? > > [Med] This is to simplify the validation checks when a certain address family > is needed. Think about simple things such as the following: > > grouping ipv4-allocation-type: > +-- prefix-length? uint8 > +-- address-allocation-type? identityref > grouping ipv6-allocation-type: > +-- prefix-length? uint8 > +-- address-allocation-type? Identityref > > When we dive into the structure, we will see that we have distinct prefix > ranges and specific types for each AF. All these checks are done using > appropriate YANG statements (e.g., to prevent that slaac is provided for an > IPv4 context). If we want to reason about a common structure for all address > families, then we will need to have a knob of the address family at the first > place and then have checks as a function of the address family, with > complicates things. > > >> >> > > ____________________________________________________________________________________________________________ > 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. > _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
