-----Message d'origine-----
De : Joel Halpern <jmh.direct@xxxxxxxxxxxxxxx>
Envoyé : mardi 3 septembre 2024 14:56
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>;
jmh@xxxxxxxxxxxxxxx; rtg-dir@xxxxxxxx
Cc : draft-ietf-opsawg-ntw-attachment-circuit.all@xxxxxxxx; last-
call@xxxxxxxx; opsawg@xxxxxxxx
Objet : Re: Rtgdir last call review of draft-ietf-opsawg-ntw-
attachment-circuit-12
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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fauth
or-
tools.ietf.org%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fboucadair.g
it
hub.io%2Fattachment-circuit-model%2Fdraft-ietf-opsawg-ntw-
attachment-c
ircuit.txt%26url_2%3Dhttps%3A%2F%2Fboucadair.github.io%2Fattachme
nt-ci
rcuit-model%2FJoel-Halpern-Review%2Fdraft-ietf-opsawg-ntw-
attachment-c
ircuit.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdecedb
e30c2
840a06fb208dccc17cd7f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
7C638
609649816696734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
joiV2
luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LnFs6bGUR
fhGQz
OeaCNPBMycdZNOhvpYluOPX0oJjhY%3D&reserved=0
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.
