Hi Éric,
Thank you for the review.
Please see inline.
Cheers,
Med
Orange Restricted
> -----Message d'origine-----
> De : Éric Vyncke via Datatracker <nore...@ietf.org>
> Envoyé : mardi 14 janvier 2025 17:16
> À : The IESG <i...@ietf.org>
> Cc : draft-ietf-opsawg-teas-attachment-circ...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org;
> luismiguel.contrerasmuri...@telefonica.com;
> luismiguel.contrerasmuri...@telefonica.com
> Objet : Éric Vyncke's No Objection on draft-ietf-opsawg-teas-
> attachment-circuit-19: (with COMMENT)
>
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-opsawg-teas-attachment-circuit-19: 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:
> -----------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-teas-
> attachment-circuit-19
> CC @evyncke
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENT points (but replies
> would be
> appreciated even if only for my own education), and some nits.
>
> Special thanks to Luis Contreras for the shepherd's detailed
> write-up including
> the WG consensus even if the justification of the intended status
> is rather
> light.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS (non-blocking)
>
> Thanks for the use of SVG graphics, it makes reading much easier
> in the HTML
> rendering.
>
> ### One or two models ?
>
> When reading the abstract and section 1, it is unclear whether
> this I-D is
> about 1 or 2 data models ? It seems that the 2 modules build one
> service data
> model...
[Med] Your observation is fair per 7950:
o data model: A data model describes how data is represented and
accessed.
o module: A YANG module defines hierarchies of schema nodes. With
its definitions and the definitions it imports or includes from
elsewhere, a module is self-contained and "compilable".
RFC 8309 echoes that distinction and adds:
YANG structures data models into modules for ease of use.
IMO, there is a room for subjective call in this I-D specific context as
bearers and ACs may be covered by same or distinct models. We assumed 1
module=1 data model for convenience because we are covering distinct properties
(bearer vs AC).
I have no major concern to reason with one single data model, if you feel
strongly about this.
>
> ### Section 1.1
>
> `This document specifies a YANG service data model ("ietf-ac-
> svc")` I think
> that "ietf-ac-svc" is a *module* and not a *model*. Of course in
> this case, the
> model includes only one module but let's try to be correct ;) The
> "ietf-bearer-svc" is also a module as it is written later in the
> section.
>
> The text is mainly about how to add a new AC but not how to
> modify or to delete
> it. Should there be some text about the lifecycle of an AC ?
Med: We are using "to manage" in the main text especially to cover not only
creation. There are few mentions of "create a new .." but this is because of
the nature of the specific example we are referring to.
If you tagged a specific occurrence that you think is worth to be clarified,
please share it and will fix that. Thanks.
>
> ### Section 1.2
>
> `The AC model specified in this document is` but this document is
> about *two*
> models...
Med: There are "AC model" and "bearer model". These two are covering distinct
aspects.
so this sentence should probably in the plural form or
> be restrictive
> to "AC service model".
>
> The section title should probably be "Positioning ACaaS model vs.
> Other Data
> Models"
Med: OK.
>
> ### Section 4.1
>
> Should there be a "b4" in figure 1 ?
Med: We could but that's not needed for the purpose of the figure. b2/b3 are
explicitly mentioned to demux the ACs terminated by the same PE and servicing
the same CE.
>
> ### Section 5
>
> The apparent confusion between model and module happens again,
> the section 5
> title is about data models but the sub-section titles are about
> YANG modules.
>
> ### Section 5.1
>
> How can a location address be changed if the location is "ro" ?
>
Med: The location under "locations" can't be changed by a customer because this
is under the control of the provider. However, the location under
"customer-point" is "rw".
> Are all location only by street/city addresses ? Should there be
> more generic
> location (especially for mobile) or more details locations (e.g.,
> floor, ...).
Med: That information may be useful in an inventory, but not for bearer
management. We considered the use of RFC 9179 (which includes more granular
info such as velocity), but we decided to not deviate from the approach adopted
in RFC 8299 and mirrored the exact structure.
>
> Please bear with my lack of knowledge about YANG language, but if
> there are
> several AC on the same location, does this mean that the location
> information
> will be repeated several times ?
Med: When multiple bearers share the same location, the duplicated location
information can be avoided by simply including a reference to the shared
location under each bearer:
+--rw provider-location-reference? String
See the use of that attribute in Figure 53, for example. That example is about
a single bearer, but shows how location information can be avoided even for a
single bearer.
>
> ### Section 5.2.1
>
> As the decision has been made, it is perhaps time to revisite the
> following
> with a more assertive tone `The rationale for deciding whether a
> reusable
> grouping should be maintained in this document or be moved into
> the AC common
> module [I-D.ietf-opsawg-teas-common-ac] is as follows`
Med: Changed to "The rationale for deciding whether a reusable grouping is
included in this .."
>
> ### Section 5.2.5.1 (and possibly others)
>
> It seems that the tree view repeats the content of imported YANG
> modules (e.g.,
> ac-common:layer2-ac) grouping, isn't there a risk of incoherency
> between two
> future RFC ?
Med: I don't think so because the trees are generated by tools. We could use
'--tree-no-expand-uses' pyang option and the tree would display as follows:
module: ietf-ac-svc
...
+---u ac-common:layer2-ac
but I prefer the expanded form of trees.
>
> ### Appendix A
>
> Reading examples with date in the future made me smile ;-)
Med: :-)
>
> And thanks for some dual-stack examples.
>
> ## NITS (non-blocking / cosmetic)
>
> The use of `Layer 2` is hurting my eyes as it should be "layer 2"
> and in some
> cases "layer-2"...
>
Med: sorry about that, but we are consistent with the use in relevant RFCs such
as RFC 9291.
>
____________________________________________________________________________________________________________
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
