Jan Kundrát

Thanks, I did not know that the OSNR at 0.1nm is a better value of these two to report. I will push this one. In general, though, I would prefer...

*@EstherLerouzic wrote:* > OSNR and SNR values are useful to see NL penalty evolution, and 0.1 and bandwidth values to fairly compare values with two different baudrate. Thanks for your...

Esther confirmed during today's call that it's indeed a use case for Orange to see both SNR-per-0.1nm and SNR-per-channel-bandwidth at the same time, so I'll be placing these back for...

Can you share the input file(s) that you're using? What numbers are you getting, and what are the expectations? Generally speaking, the transponder's Tx OSNR is taken [from the `tx_osnr`...

I believe that the description is correct. In a previous version, it said that nothing is configurable (including the launch power) which was not correct since c6432e2c (July 2018), so...

> * do absolutely not mix transponder information with SI: these are 2 different things and one of GNpy strength to be able to separate line performance from transponder performance...

Hi Jean-Luc, interesting suggestion, thanks. Right now I'm planning to go with something where we can check the validity of the input data against a YANG model. That will simplify...

Sure, we can discuss this tomorrow. It's just that I understood we were pretty much committed to YANG+JSON for a long time, with code being available since July IIRC, and...

During the call we decided to leave the feature request open for tracking, but I do not think that anyone is (actively) working on this.

I like this, and it seems that @ojnas likes this, too. Is someone against this proposal? Cc: @aleFerrari Just one thing to confirm that I understand correctly: > operator_model, which...