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

[Joel Halpern <[e-mail]>]

Thanks Med.  To confirm for everyone else.  With this hint, I was able 
to figure out how I got confused.  it was my error, the draft is fine.

Yours,

Joel

On 9/4/2024 5:21 AM, [e-mail] wrote:
> Hi Joel,
>
> Thank you for clarifiying.
>
> Actually, we do have a list of networks, each composed by a list of nodes. In order to unambiguously identify an ac, we need to supply the specific network and specific node ids. These ids are provided using "nw:node-ref" (rfc8345) and passing them in the path expression. FWIW, this construct is similar to tp-ref in RFC 8345.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Joel Halpern <[e-mail]>
>> Envoyé : mardi 3 septembre 2024 14:56
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
>> [e-mail]; [e-mail]
>> Cc : [e-mail]; last-
>> [e-mail]; [e-mail]
>> 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, [e-mail] 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 <[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.
>>>
> ____________________________________________________________________________________________________________
> 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.
>