Thank you Med.
On the issue of References, the tree diagram, and nesting. One
example. grouping attachment-circuit-reference in section 5.2 lists
three children, ac-ref2, node-ref2, and network-ref2.
However, the actual yang for attachment-circuit-reference has one leaf,
ac-ref, with type leafref, and a path. If I follow that path, I will
find a leaf node-ref, with a path, which in turn points to a
network-ref. Thus, in the YANG, it is what I would describe as nested,
which is not the same as the tree diagram. I don't know that it
matters, but I found it confusing.
Yours,
Joel
On 9/3/2024 8:11 AM, mohamed.boucadair@xxxxxxxxxx wrote:
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 <noreply@xxxxxxxx>
Envoyé : jeudi 15 août 2024 04:30
À : rtg-dir@xxxxxxxx
Cc : draft-ietf-opsawg-ntw-attachment-circuit.all@xxxxxxxx; last-
call@xxxxxxxx; opsawg@xxxxxxxx
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.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
