Search

1 to 10 of 56
Sort by

Discussion Reply
RE: YANG like model for physical equipment onboarding

Here's some of the original work: https://scienceon.kisti.re.kr/srch/selectPORSrchPatent.do?cn=USP2003076600749 Which led me to find related work such as: https://patents.google.com/patent/US8082335B2/en https://patents.google.com/patent/US7941309B2/en which talks about policy...


Discussion Reply
RE: YANG like model for physical equipment onboarding

Thank you Mario. Interesting. That looks like the kind of thing I was striving for.​ -- Paul Jordan BT Group plc --


Discussion Reply
RE: YANG like model for physical equipment onboarding

Hi Saravana, I currently work in the physical compute/NFVI space, but in the past I've worked higher up in the stack, on the HSS and earlier in the OSS space. Netconf/Yang was a thing with the HSS and we implemented a Netconf/YANG interface for the management of the HSS. In the physical compute...


Discussion Reply
RE: YANG like model for physical equipment onboarding

Hi Paul, Not for me to comment on how vendors might do that, but certainly something you can ask as a customer. Of course, I would expect BT Research Labs would have done something similar and when I was at Nortel there was a lot of collaboration going on on similar topics. The concept of...


Discussion Reply
RE: YANG like model for physical equipment onboarding

Thanks for that Dave, Interested in your opinions on if and how vendors might grant access to such capability to CSP to incorporate into their own internal processes. -- Paul Jordan BT Group plc --


Discussion Reply
RE: YANG like model for physical equipment onboarding

I used to work in the Advanced Software Engineering group in Nortel Networks during the early '90s. We applied different software techniques to different problems to see which were most effective and then turned them into products for the company. We solved these problems over 25 years ago. We...


Discussion Reply
RE: YANG like model for physical equipment onboarding

Saravana, thank you for your interest. Some years ago I noted that tools being proposed to describe the hierarchy of software capabilities and requirements could equally well be used to describe the hierarchy of equipment in things like modular routers. Eg. A port is provided on a card but a...


Discussion Reply
RE: A definition of 'machine readable'

Yes I also agree that 'machine readable' really infers machine actionable. Writing specifications in text makes it much easier to apply version management as mentioned by @Ian Turkington , which is my first suggested criteria. My second suggested criteria is that the specification must be...


Discussion Reply
RE: A definition of 'machine readable'

Yes "actionable" is a better way to think about it. I also agree that documents and code should both be version managed, allow branches, etc. I guess the difference is often tooling and velocity. But you are correct we need to consider these concepts for all our deliverable. -- Ian Turkington TM...


Discussion Reply
RE: A definition of 'machine readable'

I like the idea by @Jonathan Goldberg about distinction based on 'actionability' and would like to refine it with measures of 'freetext contamination' where human intervention is needed when actions are needed. Flows which allow 'contamination' and still work are robust and when the...