[RTG-DIR]Re: Rtgdir last call review of draft-ietf-opsawg-ntw-attachment-circuit-12

[[e-mail]]

Hi Joel,
(apologies for the delay to reply as I was out of office)

Thanks for the review.

An attempt to address your review can be seen here: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-ntw-attachment-circuit.txt&url_2=https://boucadair.github.io/attachment-circuit-model/Joel-Halpern-Review/draft-ietf-opsawg-ntw-attachment-circuit.txt

Please see more inline.

Cheers,
Med

> -----Message d'origine-----
> De : Joel Halpern via Datatracker <[e-mail]>
> Envoyé : jeudi 15 août 2024 04:30
> À : [e-mail]
> Cc : [e-mail]; last-
> [e-mail]; [e-mail]
> Objet : Rtgdir last call review of draft-ietf-opsawg-ntw-
> attachment-circuit-12
>
> Reviewer: Joel Halpern
> Review result: Ready
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and
> IESG review, and sometimes on special request. The purpose of the
> review is to provide assistance to the Routing ADs.
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with
> any other IETF Last Call comments that you receive, and strive to
> resolve them through discussion or by updating the draft.
>
> Document: draft-name-version
> Reviewer: your-name
> Review Date: date
> IETF LC End Date: date-if-known
> Intended Status: copy-from-I-D
>
> Summary:
> Choose from this list...
>
> No issues found. This document is ready for publication.
>     I have a few minor comments that should be considered.
>
> This is a truly impressive piece of work.  The editors have
> pulled together information from a myriad sources into a usable
> (if massive) YANG module that addresses the range of needs very
> well.

[Med] Glad to hear that.

>
> Major Issues: N/A
>
> Minor Issues:
>     I note that section 5.1 in discussing parent relationships
> specifies that
>     if a parent AC is deleted, all the child ACs MUST be deleted.
> Given that
>     there is no reference from a parent to its children (unless I
> missed it),
>     it seems to this reader that it would really help
> implementors to tell them
>     how this is to be done?  Are all children to be delted first,
> and the
>     client give an error if there are any active children?  Is
> the client to
>     silently find and delete all ACs which point to the deleted
> AC as a parent?
>      Or some other means?

[Med] Good point. Updated the model so that a parent AC can maintain references to its child ACs. The tree structure is updated with the following:

NEW:
     +--ro ac-child-ref
     |  +--ro ac-ref*        leafref
     |  +--ro node-ref?      leafref
     |  +--ro network-ref?   -> /nw:networks/network/network-id

Added also a sentence to refer to that in the narrative text.

Thanks for catching this.

>
>    In section 5.2 (References) in describing the groupings the
> tree diagram
>    shows a number of peer entities.  However, unless I am
> misreading the YANG,
>    they are, in almost all cases, actually nested.  Was this a
> deliberate
>    simplification, on artifact of the tree generation tool, or an
> error in my
>    reading?

[Med] I'm not sure to get the point (especially, the "peer entities"). These groupings are actually independent but are grouped in the same figure for convenience.

>
>     I note that the document refers to RIP in multiple places.
> Unless I missed
>     something, this references RIPv2, but not RIPng (RFC 20808).
> I can imagine
>     reasons for such an omission.  If there is a good reason,
> then please state
>     it.  Otherwise, sorry, please also cover 2080.
>

[Med] We do cite 2080 in 5.6.5.

I suspect that you were referring to the module itself. Updated it accordingly.
____________________________________________________________________________________________________________
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.