Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-teas-attachment-circuit-03
Hi Ebben, Please see inline. Cheers, Med > -Message d'origine- > De : Ebben Aries > Envoyé : lundi 15 janvier 2024 16:49 > À : BOUCADAIR Mohamed INNOV/NET > Cc : yang-doct...@ietf.org; draft-ietf-opsawg-teas-attachment- > circuit@ietf.org; opsawg@ietf.org > Objet : Re: Yangdoctors early review of draft-ietf-opsawg-teas- > attachment-circuit-03 > > Thx Med - one comment inline... > > On 2024-01-15 06:59:58, mohamed.boucad...@orange.com wrote: > > [External Email. Be cautious of content] > > > > ... > > > > > - For `status/admin-status/last-change`, this leaf is `r/w` > and > > > while I > > > realize this is reuse from `ietf-vpn-common`, it seems that > this > > > is > > > incorrect and should be reflected as pure `r/o` state. > > > > [Med] Actually, no. Unlike the operational status, the client > can control that for administrative status as well. Think about > scheduled operations for example. > > I'm conflicted why this would reside in modeling for the use-case > you describe as this would entail a pattern that would need to be > considered across _all_ modeling. [Med] This is fair. I'm not sure I've seen this > pattern arise before. > > RFC7758 is one such example of how scheduled operations would be > handled at the protocol messaging layer and not scattered among > the data-content. [Med] Please note that we are focusing mainly on service and network models, for which NETCONF may be the transport protocol, but I hear your point. Given that for the AC models, we do define the following for a client to control when a service can be activate/deactivated: grouping op-instructions +-- requested-start? yang:date-and-time +-- requested-stop?yang:date-and-time +--ro actual-start? yang:date-and-time +--ro actual-stop? yang:date-and-time And that for advanced scheduling, the WG is working on a generic model (draft-ma-opsawg-schedule-yang) that can be used in a future ac augments if needed, I tweaked the draft so that the admin last-change is ro instead of rw. The diff to track the changes can be seen at: * Diff ac-common: https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-common-ac.diff * diff ac-svc: https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-attachment-circuit.diff Better? Thank you for you patience. 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 https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-teas-attachment-circuit-03
Thx Med - one comment inline... On 2024-01-15 06:59:58, mohamed.boucad...@orange.com wrote: > [External Email. Be cautious of content] > > > Hi Ebben, > > Thank you for the review. > > A new version that takes into account the review can be seen at: > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-teas-attachment-circuit-04__;!!NEt6yMaO-gk!HXVDToOssxIY9VMDmKqkKUPCGGv49M5Ey707NIlh9DgCqdza_Lc--Ls96qov_kNmayL2_P2Jx6ScROMTM-o0w6Hh$ > > Please see inline for more context. > > Cheers, > Med > > > -Message d'origine- > > De : Ebben Aries via Datatracker > > Envoyé : mercredi 10 janvier 2024 23:58 > > À : yang-doct...@ietf.org > > Cc : draft-ietf-opsawg-teas-attachment-circuit@ietf.org; > > opsawg@ietf.org > > Objet : Yangdoctors early review of draft-ietf-opsawg-teas- > > attachment-circuit-03 > > > > Reviewer: Ebben Aries > > Review result: On the Right Track > > > > 2 modules in this draft: > > - ietf-ac-...@2023-11-13.yang > > - ietf-bearer-...@2023-11-13.yang > > > > YANG compiler errors or warnings (pyang 2.6.0, yanglint 2.1.128, > > yangson 1.4.19) > > - No compiler errors or warnings for tree outputs > > > > NOTE: These modules were reviewed and validated (stub instance- > > data) in conjunction with draft-ietf-opsawg-teas-common-ac-02 and > > I did my best to separate comments out to each even though > > validation crosses the 2 reviews > > > > General comments on the draft: > > - Section 5.1/5.2: Move the "file" declaration in > > up to align > > and quote the filename otherwise published IETF tooling will > > fail to parse > > correctly > > [Med] Fixed. > > > > > General comments on the modules: > > - Similar comment to that in the `ietf-ac-common` review in that > > if there is > > intention for other modules to import and use then ensure any > > must/when > > statements are fully qualified. L#272-273 in `ietf-bearer-svc` > > are one such > > example. > > [Med] ACK. > > > - For `status/admin-status/last-change`, this leaf is `r/w` and > > while I > > realize this is reuse from `ietf-vpn-common`, it seems that > > this is > > incorrect and should be reflected as pure `r/o` state. > > [Med] Actually, no. Unlike the operational status, the client can control > that for administrative status as well. Think about scheduled operations for > example. I'm conflicted why this would reside in modeling for the use-case you describe as this would entail a pattern that would need to be considered across _all_ modeling. I'm not sure I've seen this pattern arise before. RFC7758 is one such example of how scheduled operations would be handled at the protocol messaging layer and not scattered among the data-content. `last-change` also seems like a misnomer here for the administrative client induced use-case which I don't see mention of intent within RFC9181. > A > > client is not > > going to "write" this value to a server however this is an > > inheritance/reuse > > issue if you agree > > > > Example Validated Instance Data (post qualification fixes): > > [Med] Thank you. I put this example at > https://urldefense.com/v3/__https://github.com/boucadair/attachment-circuit-model/blob/main/xml-examples/svc-full-instance.xml__;!!NEt6yMaO-gk!HXVDToOssxIY9VMDmKqkKUPCGGv49M5Ey707NIlh9DgCqdza_Lc--Ls96qov_kNmayL2_P2Jx6ScROMTM7M963ko$ > and cited it in the draft with an acknowledgement :-) > > > > > > > > > KC1 > > KC1 Description > > > > 131001 > > > > > > > > > > > > hmac-sha-512 > > > > > > > > > > > > AGP1 > > SPP1 > > SPP2 > > > > > > > xmlns:vpn-common="urn:ietf:params:xml:ns:yang:ietf-vpn- > > common">vpn-common:ethernet-type > > > > > > > > > > AGP2 > > SPP1 > > > > > > 1.1.1.1 > > 2.2.2.2 > > 31 > > > xmlns:ac-common="urn:ietf:params:xml:ns:yang:ietf-ac- > > common">ac-common:static-address > > > > ID1 > > 10.1.1.1 > > > > > > > > 2001:db8:1000::1 > > 2001:db8::: > > 127 > > > xmlns:
Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-teas-attachment-circuit-03
Hi Ebben, Thank you for the review. A new version that takes into account the review can be seen at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-teas-attachment-circuit-04 Please see inline for more context. Cheers, Med > -Message d'origine- > De : Ebben Aries via Datatracker > Envoyé : mercredi 10 janvier 2024 23:58 > À : yang-doct...@ietf.org > Cc : draft-ietf-opsawg-teas-attachment-circuit@ietf.org; > opsawg@ietf.org > Objet : Yangdoctors early review of draft-ietf-opsawg-teas- > attachment-circuit-03 > > Reviewer: Ebben Aries > Review result: On the Right Track > > 2 modules in this draft: > - ietf-ac-...@2023-11-13.yang > - ietf-bearer-...@2023-11-13.yang > > YANG compiler errors or warnings (pyang 2.6.0, yanglint 2.1.128, > yangson 1.4.19) > - No compiler errors or warnings for tree outputs > > NOTE: These modules were reviewed and validated (stub instance- > data) in conjunction with draft-ietf-opsawg-teas-common-ac-02 and > I did my best to separate comments out to each even though > validation crosses the 2 reviews > > General comments on the draft: > - Section 5.1/5.2: Move the "file" declaration in > up to align > and quote the filename otherwise published IETF tooling will > fail to parse > correctly [Med] Fixed. > > General comments on the modules: > - Similar comment to that in the `ietf-ac-common` review in that > if there is > intention for other modules to import and use then ensure any > must/when > statements are fully qualified. L#272-273 in `ietf-bearer-svc` > are one such > example. [Med] ACK. > - For `status/admin-status/last-change`, this leaf is `r/w` and > while I > realize this is reuse from `ietf-vpn-common`, it seems that > this is > incorrect and should be reflected as pure `r/o` state. [Med] Actually, no. Unlike the operational status, the client can control that for administrative status as well. Think about scheduled operations for example. A > client is not > going to "write" this value to a server however this is an > inheritance/reuse > issue if you agree > > Example Validated Instance Data (post qualification fixes): [Med] Thank you. I put this example at https://github.com/boucadair/attachment-circuit-model/blob/main/xml-examples/svc-full-instance.xml and cited it in the draft with an acknowledgement :-) > > > > KC1 > KC1 Description > > 131001 > > > > > > hmac-sha-512 > > > > > > AGP1 > SPP1 > SPP2 > > > xmlns:vpn-common="urn:ietf:params:xml:ns:yang:ietf-vpn- > common">vpn-common:ethernet-type > > > > > AGP2 > SPP1 > > > 1.1.1.1 > 2.2.2.2 > 31 > xmlns:ac-common="urn:ietf:params:xml:ns:yang:ietf-ac- > common">ac-common:static-address > > ID1 > 10.1.1.1 > > > > 2001:db8:1000::1 > 2001:db8::: > 127 > xmlns:ac-common="urn:ietf:params:xml:ns:yang:ietf-ac- > common">ac-common:static-address > > ID1 > 2001:db8:dead::beef address> > > > > > > RP1 > xmlns:vpn-common="urn:ietf:params:xml:ns:yang:ietf-vpn- > common">vpn-common:bgp-routing > > EPI5 > xmlns:vpn-common="urn:ietf:params:xml:ns:yang:ietf-vpn- > common">vpn-common:import-export > > > > > PG1 > 65000 > 65001 > xmlns:vpn-common="urn:ietf:params:xml:ns:yang:ietf- > vpn-common">vpn-common:ipv4 > 10.1.1.1 > > true > > true > KC1 > > > > > > N1 > 10.2.2.2 > 10.1.1.1 > PG1 > > > xmlns:vpn- > common="urn:ietf:params:xml:ns:yang:ietf-vpn-common">vpn- > common:admin-up > 2023-12-30T15:02:11.353Z change> > > > xmlns:vpn- > common="urn:ietf:params:xml:ns:yang:ietf-vpn-common">vpn- > common:op-up >
[OPSAWG] Yangdoctors early review of draft-ietf-opsawg-teas-attachment-circuit-03
Reviewer: Ebben Aries Review result: On the Right Track 2 modules in this draft: - ietf-ac-...@2023-11-13.yang - ietf-bearer-...@2023-11-13.yang YANG compiler errors or warnings (pyang 2.6.0, yanglint 2.1.128, yangson 1.4.19) - No compiler errors or warnings for tree outputs NOTE: These modules were reviewed and validated (stub instance-data) in conjunction with draft-ietf-opsawg-teas-common-ac-02 and I did my best to separate comments out to each even though validation crosses the 2 reviews General comments on the draft: - Section 5.1/5.2: Move the "file" declaration in up to align and quote the filename otherwise published IETF tooling will fail to parse correctly General comments on the modules: - Similar comment to that in the `ietf-ac-common` review in that if there is intention for other modules to import and use then ensure any must/when statements are fully qualified. L#272-273 in `ietf-bearer-svc` are one such example. - For `status/admin-status/last-change`, this leaf is `r/w` and while I realize this is reuse from `ietf-vpn-common`, it seems that this is incorrect and should be reflected as pure `r/o` state. A client is not going to "write" this value to a server however this is an inheritance/reuse issue if you agree Example Validated Instance Data (post qualification fixes): KC1 KC1 Description 131001 hmac-sha-512 AGP1 SPP1 SPP2 vpn-common:ethernet-type AGP2 SPP1 1.1.1.1 2.2.2.2 31 ac-common:static-address ID1 10.1.1.1 2001:db8:1000::1 2001:db8::: 127 ac-common:static-address ID1 2001:db8:dead::beef RP1 vpn-common:bgp-routing EPI5 vpn-common:import-export PG1 65000 65001 vpn-common:ipv4 10.1.1.1 true true KC1 N1 10.2.2.2 10.1.1.1 PG1 vpn-common:admin-up 2023-12-30T15:02:11.353Z vpn-common:op-up 2023-12-30T15:02:11.353Z EPI3 180 vpn-common:admin-up 2023-12-30T15:02:11.353Z vpn-common:op-up 2023-12-30T15:02:11.353Z true layer3 KC1 vpn-common:bw-per-service 1 1 1 1 1 1 vpn-common:pop-diverse GID1 AC1 CUSTOMER1 Attachment Circuit #1 2023-12-30T14:52:51.353Z 2025-12-30T00:00:00.000Z 2023-12-30T15:02:10.003Z PSID1 AGP2 AC2 GID1 ac-common:primary vpn-common:l3vpn SID1 SPP1 2001:db8::1 2001:db8::2 128 ac-common:static-address EPI2 vpn-common:both EPI4 AC2 EPI1 EPI2 EPI3 EPI4 EPI5 SPP1 SPP2 network-termination-hint G1 vpn-common:pop-diverse vpn-common:pe-diverse B1 Description for B1 G1 Op comment site-and-device-id devid1 SJC01 555 Anystreet 95123 CA San Jose US ethernet AC1 2023-12-30T14:52:51.353Z 2025-12-30T00:00:00.000Z 2023-12-30T15:02:10.003Z vpn-common:admin-up 2023-12-30T15:02:11.353Z vpn-common:op-up 2023-12-30T15:02:11.353Z ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
