Eugene Khavinson

This is a live, multi-phase project I expect to be working through most of next year: certifying the newest cell-backhaul platform, Ciena 3931-Gen2, to replace the older Gen1 devices — including the move from SNMP to NETCONF for configuration and management.

Rather than just running the migration, I'm using it as the proving ground for reducing test cycle time going forward: building out test automation and an AI-assisted documentation agent alongside the certification work itself, so the tooling gets better as the project does.

Led the initiative to succeed legacy 39xx platforms with the 3928, authoring the deployment guidelines and configuration migration procedures used for both lab and field adoption.

D2EMUX was my introduction to Ciena's SAOS 10.x architecture — a real departure from the SAOS 6.x devices I'd worked on before. I tested and certified gNMI telemetry sensors, configuration RPCs, end-to-end traffic passing, and the migration to Ciena's Trusted Partner Licensing Model (TPLM).

The TPLM piece is the part I'd point to first: previously, a device had to check back in with a license server roughly every week to stay licensed. TPLM replaces that with a license that's verified once and then persists permanently — surviving even a factory reset. Certifying it meant proving that held up under the edge cases that actually matter in production, not just the happy path.

I also owned the documentation for it end to end: an Integration Guide for external integrators, covering everything that changed from the previous phase, and a separate production Deployment Guide — two different audiences, written from the same validation work.

This site is end-to-end my own infrastructure, not just a repo of HTML. The domain is registered and resolved through Route 53; a public ACM certificate, validated by DNS, gives it TLS; CloudFront terminates that TLS and serves the site from a private S3 bucket that isn't reachable directly. Nothing here is a tutorial copy-paste — the DNS validation records, the origin access policy limiting S3 to CloudFront only, and the certificate region requirement (ACM certs for CloudFront have to live in us-east-1 regardless of where everything else sits) all came from working through the actual failure modes.

Security testing came before making any of this public: a full-history gitleaks scan of the repo to make sure nothing had ever leaked (it hadn't), GitHub's own secret scanning and push protection turned on going forward, and an S3 bucket policy scoped so only the CloudFront distribution's origin access control can read it — the bucket itself has no public access at all.

On top of that sits the deploy pipeline: a push to main runs a GitHub Actions workflow that federates into AWS via OIDC and syncs to S3 behind CloudFront — no long-lived AWS access keys stored anywhere. I treated making the repo public as a reason to actually audit that pipeline rather than just hope it held up, rebuilding the AWS side around scoped, short-lived trust instead of static credentials.

The OIDC trust policy took a few rounds to get right — GitHub's token subject format doesn't just encode the repo and branch, it also changes shape entirely once a job references a GitHub Environment. I traced both mismatches through the actual CloudTrail AssumeRoleWithWebIdentity events rather than guessing, then split the workflow into an ungated dry-run preview and a real deploy job gated behind a production Environment that requires a manual approval click before anything touches S3 or CloudFront.

Along the way I caught a quieter problem: GitHub Environments let repo admins bypass their own required-reviewer rule by default, which would have made the new approval gate a no-op for the only account that ever triggers a deploy. Turning that off, pinning every third-party Action to a commit SHA, and tightening branch protection were the guardrails that actually made the public repo, and the pipeline behind it, something I'd stand behind.