Hi Benoit, On Tue, Jun 28, 2022 at 7:16 PM Benoit Claise <benoit.cla...@huawei.com> wrote:
> Hi Dhruv, > > Thanks for reviewing the draft. > See inline. > > On 6/26/2022 4:04 PM, Dhruv Dhody wrote: > > Hi WG, > > I think this work is very useful. I have some comments (also see my review > of the architecture I-D). > > Minor > - In the text of the I-D, we should explain that the symptoms are targeted > at humans and not machines. > > That might be the case now, but this is obviously not the end goal, as we > want to solve closed loop automation. > So we propose not to mention it. > Dhruv: Ok. I wonder if "string" is the best way to model symptoms in that case. I understand that having an identity for all possible symptoms would be challenging. Perhaps a mix of some well-known symptoms plus the current free-form! I will leave that for you to do the right thing as you are the expert here :) - Architecture talks about circular dependencies and states that it is > likely to show up; shouldn't the YANG model add a notification saying > circular dependency detected? > > Next to the notification, the higher level question is: what's happening > in case of circular dependencies configuration? > So instead of the notification, we might stress in the draft that > circulation dependencies should be not be accepted by the implementation. > Btw, that's something we can't impose from a YANG language point of view. > > Dhruv: I am fine with that and the rest of your responses! Thanks! Dhruv - Security Considerations skips talking about readable leaves. > > Thanks. We're going to review this section according to > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines > > - For example-service-assurance-device-acme, wouldn't it make more sense > to augment the ietf-service-assurance-device instead of > ietf-service-assurance? > > Yes, we could. Actually, it depends whether the ietf-service-assurance-device > is generic enough. As this is an example, we propose not to change that. We > could add: "it's an implementation choice to either augment the identity > from ietf-service-assurance or to augment the parameters from > ietf-service-assurance-device" > > - I am wondering what is the best practice for example YANG module - > copyright to IETF, organization, and contact to be IETF? It reads weird esp > for a vendor-specific model example in the appendix A! > > https://www.rfc-editor.org/rfc/rfc8407.html#section-3.2.1 is not clear. > Good point. Let's remove the IETF references. > > > Nits > - In the IANA section, the Registrant Contact is mentioned as NETCONF WG. > > Well spot. > > Regards, Benoit > > Thanks! > Dhruv > > On Wed, Jun 8, 2022 at 3:34 PM Tianran Zhou <zhoutianran= > 40huawei....@dmarc.ietf.org> wrote: > >> Hi WG, >> >> >> >> This mail we start a two weeks working group last call for >> draft-ietf-opsawg-service-assurance-yang-05. >> >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/ >> >> >> >> Please send over your comments before June 22. >> >> Please also indicate if you think this document is ready to progress. >> >> >> >> Cheers, >> >> Tianran, on behalf of chairs >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > _______________________________________________ > OPSAWG mailing listOPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg > > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
