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
