Rupesh Shrestha and the NPIX Community Record Behind Nepal Internet Exchange

Summary

• Rupesh Shrestha appears in a dated public chain that begins with the March 2002 NPIX working group and later includes NPIX Managing Director, SANOG Chair, programme and routing-security roles.
• The record supports an analysis of operator-community stewardship and technical capacity building, but it does not establish sole founding, personal ownership of NPIX, completed national RPKI deployment, independently audited traffic success or control over entity networks.

A person-level record inside a collective institution

Internet exchanges are collective infrastructure. They exist because networks agree to meet under technical and institutional rules that none of them can establish alone. The equipment matters, but the equipment does not convene competitors, define neutral operating expectations, train engineers or sustain a community through changes in technology and membership.

Rupesh Shrestha appears in public records at that organisational layer. An APNIC Blog history of NPIX names him among the local ISP operators in a working group formed in March 2002. The same account describes a wider group, outside advisers and a sequence of committee formation, training, site negotiation and exchange launch. It does not assign that sequence to Rupesh alone.

Later public records place him in different but related contexts. The SANOG35 programme lists him as SANOG Chair and records moderator and update roles. An NPIX page about an online routing-security programme identifies him as NPIX Managing Director and attributes comments about routing-security implementation and NPIX support for RPKI deployment efforts. The npNOG10 programme lists a welcome by the NPIX Managing Director and SANOG Chair and also records the name variant Rupesh Bhakta Shrestha as a session chair.

Those records are enough for a bounded leadership profile. They show continuity across an exchange, a regional network-operator group and a national training forum. They do not provide a complete employment history, a private biography or an audited account of individual performance.

That distinction matters. Technical-community work is often reported through institutions, event programmes and working groups. A person can be visible over time without being the sole cause of every institutional result. The supported question is therefore not whether Rupesh "built Nepal's Internet." It is how his public roles illuminate the work required to maintain an exchange community and connect it to wider operational practice.

The March 2002 working group and the discipline of attribution

The APNIC account provides the earliest person-level evidence in this source set. It says a working group was formed in March 2002 and lists Rupesh Shrestha with Gaurab Raj Upadhaya, Ritesh Raj Joshi, Binay Bohra, Dileep Agrawal, Krishna Shah and Alok Tuladhar, all described as working at local ISPs. It also names Bill Woodcock and Philip Smith as advisers with experience establishing exchanges elsewhere.

The list is important because it prevents ownership inflation. NPIX did not emerge in the account as a private project attached to one person. It emerged from a group of operators and advisers confronting a shared technical and economic problem. Naming every entity is not a ceremonial detail; it shows that the first institutional unit was a working group.

APNIC's article says that within less than seven months the group formed a committee, organised initial training, negotiated a centrally located site for a switch and launched the first NPIX exchange point. It reports that the exchange initially connected three members. These are organisation-level statements in an APNIC narrative published years later, not a minute-by-minute record of who performed each task.

For Rupesh, the defensible claim is precise: APNIC names him as a member of the March 2002 working group. The source does not say he alone formed the committee, selected the site, configured the equipment, recruited the initial members or supplied the external expertise. Assigning any of those actions specifically to him would require evidence that is not present here.

That restraint does not make the working-group evidence trivial. Early exchange projects depend on people being willing to work across organisational boundaries. Engineers employed by different providers have to discuss common technical requirements without dissolving the commercial independence of their networks. A working group creates a place for that bounded cooperation.

Rupesh's inclusion shows that his public connection to NPIX extends back to the institution's formative phase. The later role records therefore do not appear as an isolated title. They sit after an earlier, named participation in the group that APNIC associates with the exchange's establishment.

Committee, training and site work as a shared operating sequence

The APNIC history describes several categories of work before the first exchange point launched: committee formation, training, site negotiation and technical implementation. These categories remain useful because they separate institution building from equipment installation.

A committee establishes a decision surface. It can define who participates, how different interests are heard and where responsibility sits. Training establishes a capability surface. Engineers need enough shared understanding of routing and exchange operations to connect without creating avoidable instability. Site negotiation establishes a trust and access surface. Networks have to accept where equipment is located and how that location relates to their own infrastructure.

The article also describes changes after launch. It says early member connectivity was constrained and that the committee later added a second switch in a location where more providers already had suitable connections. It then reports a later move to a neutral data centre as fibre availability improved. These details belong to NPIX's institutional history, not to Rupesh's personal performance record.

Their relevance to his profile is indirect but meaningful. He is named in the working group that preceded an institution capable of making and revisiting these choices. A leadership analysis can examine that process without crediting him with every decision. The record supports participation in the formative group; it does not disclose his vote, assigned task list or authority.

The sequence also shows why exchange stewardship cannot end at launch. A first configuration may reflect the constraints of the moment. Member connectivity changes. Neutrality expectations evolve. Training needs recur as new engineers and networks arrive. An exchange has to adjust while keeping the cooperation that justified it.

Rupesh's later visibility in NPIX and operator-group programmes is consistent with this ongoing requirement. It does not prove uninterrupted responsibility for every intermediate year. It does show that the same name appears in both an account of the early working group and later public role records.

Community is a technical control, not a slogan

The APNIC article frames NPIX through community cooperation. That language can sound promotional if repeated without analysis, but it points to an operational dependency. An exchange cannot compel independent networks to route traffic through it merely by existing. Participation depends on confidence in the technical environment, institutional arrangements and expected conduct.

Community, in this setting, is not the absence of rules. It is a way of producing and revising rules among organisations that retain their own interests. Operators can share troubleshooting experience, develop common training and discuss routing practices while continuing to compete elsewhere.

The working-group structure is one observable form of that cooperation. Regional and national operator forums are another. They create repeated opportunities to explain changes, compare practice and expose assumptions to technical peers. The SANOG and npNOG programme records place Rupesh in those public settings.

This is where person-level continuity can matter. Institutions often rely on people who can translate between local operations, regional discussions and training programmes. The sources do not describe Rupesh's private network of relationships or the specific conversations he led. They do show public roles on multiple stages where such translation is possible.

The leadership standard should therefore remain procedural. Did the person appear in accountable, named roles? Did the institution provide forums where claims could be heard and challenged? Did the public record distinguish exchange operations from the interests of any one entity? These questions are better supported than claims about charisma or personal vision.

Rupesh's record provides indicators, not a complete evaluation. The working-group listing, programme roles and NPIX title connect him to the community process. They do not prove that every entity agreed with every decision, that membership was equally accessible or that all training produced lasting operational change.

SANOG35 and the public role chain

The SANOG35 programme is a different kind of source from the APNIC history. A conference programme is strong evidence that a session and role were publicly scheduled. It is not an independent assessment of the session's quality, impact or factual conclusions.

Within that boundary, the programme provides useful role detail. It lists Rupesh Shrestha as SANOG Chair and records him in moderator and update contexts, including an NPIX update. The combination connects an institutional exchange role to a regional operator-community forum.

Chair, moderator and presenter are not interchangeable labels. A chair role indicates a published position in the event or organisation. A moderator role indicates responsibility for a scheduled discussion. An update presentation indicates public communication about an institution or programme. None of these labels discloses the work performed before or after the event.

Their value is cumulative. The programme does not simply mention Rupesh as an attendee. It places him at several visible points in the event structure. That visibility creates a form of accountability because claims delivered in a programme can be associated with a named speaker and institutional context.

The programme should not be stretched into a claim that Rupesh governed SANOG alone or directed every technical subject at the event. SANOG is a regional community with many organisers, speakers, volunteers and entities. The record supports a chair title and scheduled roles, not ownership of the community.

It also should not be used to claim that SANOG endorses this profile. The programme is evidence of scheduled public roles. The analysis and conclusions here remain editorial and are not statements by SANOG, NPIX, APNIC or npNOG.

The NPIX Managing Director record without ownership inflation

The NPIX routing-security programme page identifies Rupesh Shrestha as Managing Director of NPIX. This is first-party role evidence: the organisation presents the title on its own page. It is appropriate for establishing how NPIX publicly described his role at the time represented by the archived page.

The title does not establish personal ownership of the exchange. An internet exchange is an institution with members, technical systems and governance arrangements. A managing director can have significant responsibility without owning entity networks, controlling their routing policies or acting without oversight.

The page does not provide a full job description, delegation instrument, term history, reporting line or performance review. It therefore cannot support detailed claims about his authority. It can support the narrower statement that NPIX publicly identified him as Managing Director in connection with the programme.

This distinction is especially important because executive titles invite assumptions. Readers may infer that the title includes sole control over operations, budget, membership or policy. Those inferences would need documents that are not in this record.

The useful leadership question is instead what kind of interface the title made visible. A named managing director gives external entities a public point of institutional responsibility. In a training or routing-security context, that can connect a technical initiative to the exchange organisation rather than leaving it as an informal project.

Rupesh's earlier working-group listing and later managing-director title create a long arc, but the sources do not fill every year between them. The arc supports continuity of association with NPIX, not a claim of uninterrupted tenure in one office or sole custody of institutional knowledge.

Routing security as enablement, not a completed outcome

The NPIX page says Rupesh stressed the importance of routing-security implementations in Nepal and describes NPIX support for RPKI deployment efforts. Because this is first-party material, the claim should remain attributed to NPIX and to the programme context.

The wording supports a capacity-building interpretation. Routing security is not implemented nationally by declaration. Networks make their own operational changes, publish and maintain routing information, validate routes and integrate new controls into production practice. Training and institutional support can lower barriers, but they do not substitute for deployment by each network.

The source does not provide a national completion rate, independent measurement or list of networks that changed configuration after the programme. It does not show that Rupesh personally implemented RPKI for participating operators. It therefore would be inaccurate to describe him as having completed Nepal's RPKI deployment.

What the record can show is public advocacy and programme responsibility. NPIX connected its managing director to a routing-security event and described support for deployment efforts. That places the institution and the named person inside a capacity-building chain.

The distinction between enablement and completion is a core accountability boundary. Enablement can include organising sessions, connecting trainers and operators, explaining why a practice matters and making institutional resources available. Completion requires evidence from the networks that adopt and operate the practice.

Rupesh's record is meaningful at the enablement layer. It links exchange stewardship to a security topic that extends beyond the exchange fabric itself. It does not convert an exchange organisation into a regulator or a programme into proof of nationwide operational change.

npNOG10 as a dated accountability surface

The npNOG10 programme adds a later dated record. It lists a welcome by "NPIX Managing Director and SANOG Chair: Rupesh Shrestha." It separately records Rupesh Bhakta Shrestha as a session chair and includes Rupesh Shrestha in speaker and volunteer recognition.

This programme is useful for three reasons. First, it repeats the NPIX Managing Director and SANOG Chair role pairing in another organisational context. Second, it associates the name with specific programme positions rather than a generic biography. Third, it provides the fuller name variant that should be retained for identity hygiene.

Name variants require caution. A programme can abbreviate or expand a name without explaining whether all instances refer to the same person. Here the institutional and programme context supports treating Rupesh Shrestha and Rupesh Bhakta Shrestha as aliases in the directory record, but the variant should not be used to merge unrelated records elsewhere.

The event listing does not show what Rupesh said in the welcome, how he chaired the session or what work supported the volunteer recognition. It establishes scheduled and published roles. Any deeper account would require recordings, slides, minutes or interviews.

Programmes are sometimes dismissed as weak sources because they do not independently verify impact. That limitation is real, but their evidentiary value is not zero. They create dated records of who was publicly assigned to what role. For community institutions, that assignment is part of the accountability structure.

The npNOG programme also demonstrates that the public role chain continued beyond one SANOG event. Rupesh appears in a national operator-group setting connected to NPIX and SANOG. The record supports continuity across forums without implying control over either community.

The NPIX author archive and the limits of first-party evidence

The NPIX author archive for Rupesh groups first-party posts associated with his name. It offers evidence that NPIX published operational and event material under that author identity. It is not an independent profile of Rupesh or an audit of the claims in those posts.

First-party evidence is valuable for roles, announcements and how an institution describes its own work. It becomes risky when promotional language is repeated as settled outcome evidence. An exchange may report traffic milestones or event success, but a public profile should distinguish that report from independently measured performance.

The source set notes NPIX posts about local traffic crossing a stated threshold and about event hosting. Those statements can be described as NPIX's own published claims if they are material to the analysis. They should not be converted into an independently audited measure of Rupesh's performance.

This profile does not need a traffic milestone to establish the person-level record. The stronger chain comes from the APNIC working-group history, the NPIX managing-director page and the SANOG and npNOG programme roles. The author archive adds continuity of public communication.

It also provides a lesson for institutional transparency. Publishing updates under named authors makes responsibility more visible than anonymous organisational copy. Yet authorship alone does not reveal who collected data, reviewed a claim or approved publication.

The responsible use of the archive is therefore bounded: it shows NPIX material associated with Rupesh's author identity. It does not prove sole authorship of every institutional action described, nor does it establish independent accuracy for performance statements.

Two exchange entities as topology context

The PeeringDB NPIX exchange-entity query provides structured, capture-time context. In the archived response reviewed for this profile, it returned two NPIX exchange entities: npIX DH in Kathmandu and npIX AWT in Lalitpur.

The entities connected both entries to the NPIX website and reported directory net_count values of 30 and 18. These figures describe fields in a PeeringDB snapshot. They are not a census conducted for this article and should not be treated as independently audited membership or traffic measurements.

The entities also do not establish Rupesh's personal responsibility for either location. PeeringDB records an exchange entity and its public attributes. It does not assign institutional decisions or daily operations to the NPIX managing director.

Their value is to make the institutional environment more concrete. NPIX appears not only in historical narrative and programme pages but also as multiple exchange entities in a widely used public directory. That context helps explain why community coordination and training can persist after an initial launch.

The two-location view also warns against a simple origin story. Institutions change topology over time. A profile focused only on the 2002 launch would miss the later operational context represented by DH and AWT. At the same time, the snapshot cannot explain how or why each entity was established.

No street address, contact field or private operational detail is needed for this analysis. The relevant public fields are the exchange names, cities, country, website association and capture-time counts. Removing unrelated details preserves privacy and keeps the evidence aligned with the institutional question.

What the netixlan snapshots can and cannot show

Separate PeeringDB netixlan queries for npIX DH and npIX AWT add another layer of structured context. The archived responses contained 31 rows for DH and 18 for AWT.

Those row counts are not automatically equivalent to unique active members. A network can appear more than once, records can include different configurations and an operational field represents directory data rather than an independent live test. The DH snapshot, for example, included rows marked non-operational as well as operational rows.

The records therefore support a limited statement: at capture time, PeeringDB returned public netixlan rows associated with the two NPIX exchange entities. They do not prove traffic volume, availability, commercial significance or entity satisfaction.

The same boundary applies to speed fields. A configured port speed in a directory is not a measurement of sustained traffic and cannot be added across rows to derive exchange throughput. It indicates a reported connection attribute in the snapshot.

This distinction protects the article from two opposite errors. The presence of many rows should not be inflated into a claim of audited exchange success. The presence of non-operational rows should not be inflated into a claim of failure. Both would exceed what the directory data establishes.

For a leadership profile, the topology snapshots are environment evidence. They show an exchange institution with multiple entities and public connection records. They do not turn Rupesh into the operator of every listed network or make him personally responsible for the condition of every row.

Registry context is not biography

The source set includes a redacted APNIC RDAP record for AS45170. It places an autonomous-system record in Nepal and provides structured registry context for the environment represented in the exchange data.

RDAP records can contain contact and registration fields that are irrelevant to a public leadership profile. No email address, phone number, street address, vCard, registry handle or other personal data is needed here. The relevant point is only that the record exists as infrastructure context.

The record does not identify Rupesh as the registrant or operator and should not be used as person-level evidence. Its inclusion is useful precisely because the boundary is explicit. Not every data source connected to an exchange environment can support a claim about the person profiled.

This is an important discipline in technical reporting. Structured registries make it easy to collect large amounts of information. More information does not automatically produce a stronger biography. Evidence has to be matched to the claim it can support.

The person-level chain in this profile comes from named working-group and programme records. The RDAP entity remains outside that chain. It helps describe the network environment but cannot establish Rupesh's title, action or responsibility.

Keeping registry context separate from biography also reduces privacy risk. A public-interest analysis can explain institutional topology without reproducing operational contacts or converting administrative records into personal narratives.

Operator-community stewardship across institutional boundaries

Taken together, the records place Rupesh at three institutional interfaces. NPIX is the exchange organisation. SANOG is a regional network-operator community. npNOG is a national operator forum and training context. The APNIC article provides an external narrative about the early NPIX working group.

Each institution has a different role. NPIX concerns local interconnection and the exchange community. SANOG creates a regional forum for operational knowledge. npNOG provides a national venue for technical sessions and capacity building. APNIC supplies registry and technical-community context but does not own NPIX.

Rupesh's public roles connect these surfaces without collapsing them. A managing-director title at NPIX does not make him the owner of SANOG. A SANOG Chair listing does not grant authority over entity networks. A welcome at npNOG does not prove implementation of every technique discussed there.

The leadership value lies in the interface. Exchange institutions need channels through which operators can learn, compare and revisit practice. Regional forums can expose local work to broader operational experience. National programmes can make advanced topics accessible to engineers who will implement them in their own networks.

The sources do not document how Rupesh allocated time among these roles or which outcomes followed from a particular event. They do show repeated public association with the institutional interfaces themselves.

That is a useful form of stewardship evidence. It is procedural, visible and bounded. It says more than a generic executive biography while avoiding claims the record cannot support.

Continuity without a claim of uninterrupted authority

The public timeline spans the 2002 working group, a 2018 APNIC history, SANOG35 in 2020, an NPIX routing-security programme and npNOG10 in 2024. This creates an impression of continuity, but the evidence has gaps.

It would be reasonable to say that Rupesh's name appears across records separated by many years. It would not be reasonable to infer that he held one uninterrupted office throughout the entire period. The sources do not provide a complete tenure chronology.

Continuity of association and continuity of authority are different claims. The first is supported: he appears in the early working-group account and later institutional roles. The second would require dated appointment, term or governance documents.

This distinction also affects institutional-memory arguments. A person associated with an organisation over a long period may carry experience, but the sources do not describe what knowledge Rupesh personally retained, documented or transferred. The article should not assign him sole custody of NPIX's history.

The supported observation is that his public role chain crosses formative, managerial and community-facing contexts. That makes him a useful lens for examining how an exchange institution remains connected to operator communities over time.

The gaps are not defects to be concealed. They are part of the confidence boundary. A precise profile can identify a durable public association while stating that tenure and authority details remain incomplete.

Distinct from other Nepal infrastructure narratives

Nepal's Internet history already includes stories about institutional authority, root-key custody, local cloud continuity, data centres and retail access economics. Rupesh's record should not be used to retell those narratives under a new name.

The NPIX working-group evidence is specifically about local interconnection and operator cooperation. The SANOG and npNOG records are specifically about public technical-community roles. The NPIX routing-security page is specifically about an exchange organisation supporting security capacity building.

This profile therefore does not make claims about national Internet governance as a whole. It does not discuss DNS root-key ceremonies, cloud continuity, power and cooling economics, consumer broadband prices or cross-border transit as its central thesis.

The routing-security element also has a narrow boundary. Other public figures have substantial records in global routing-security research and standards. Rupesh's evidence here concerns NPIX and operator-community enablement in Nepal. It is not a general history of RPKI or global BGP security.

Maintaining these distinctions matters for both fairness and information value. Repeating a familiar national narrative would obscure the specific evidence attached to Rupesh. Inflating his record would also erase the work of other people and institutions.

The article's distinct contribution is a person-level account of exchange-community stewardship: named participation in the early working group, later NPIX responsibility, regional programme visibility and national capacity-building context.

Leadership measured by visible responsibility

Infrastructure leadership is often described through scale, capital or formal power. Operator communities also rely on a quieter form of leadership: visible responsibility for convening, explaining and sustaining shared technical work.

The sources provide several visible responsibility markers. APNIC names Rupesh in the early working group. NPIX identifies him as Managing Director in a routing-security programme. SANOG35 lists him as Chair and in moderator and update roles. npNOG10 lists a welcome and session role.

These markers do not establish effectiveness by themselves. A title can be nominal. A programme can be well attended or poorly attended. A working group can produce uneven results. Independent evaluation would require more evidence.

They do establish that the roles were public and attributable. That visibility matters because technical communities often depend on informal labour that is difficult to inspect. Naming roles creates a basis for questions about responsibility, continuity and follow-through.

For Rupesh, the strongest supported leadership claim is therefore about participation across accountable surfaces. He appears where a local exchange, a regional operator forum and a national programme make their work public.

The conclusion should remain proportionate. The record shows stewardship signals, not proof that he caused every NPIX outcome or solved Nepal's routing-security challenges.

What the public evidence still does not establish

The first missing category is governance detail. The reviewed sources do not provide NPIX bylaws, board minutes, voting procedures, delegation records or a complete chronology of executive appointments. Those documents would clarify the exact authority attached to the Managing Director role.

The second is current operational measurement. PeeringDB supplies directory entities and connection rows, but not an independent live audit of traffic, availability, route quality or member experience. NPIX first-party traffic statements remain organisation-published claims.

The third is programme outcome evidence. The routing-security page and conference programmes show that activities were announced and roles were assigned. They do not show which networks changed configuration, how deployments were maintained or whether risk was reduced.

The fourth is Rupesh's individual work product. The records do not identify specific policies he wrote, configurations he changed, decisions he approved or teams he managed. A fuller profile would need dated documents or interviews that make those contributions explicit.

The fifth is participation breadth. The public record does not provide a denominator of networks that chose not to join NPIX, declined training or remained concerned about neutrality, cost or governance.

The sixth is tenure. The long span between the working-group account and later role listings demonstrates recurring association but not uninterrupted office. Appointment and departure dates would be needed for a complete timeline.

These gaps limit the conclusion but do not erase the person-level record. They define what future reporting should verify.

Questions for the next stage of reporting

What responsibilities are formally assigned to the NPIX Managing Director, and which decisions belong to a board, members or technical staff? A published role description would make the accountability chain clearer.

How did the early working group divide tasks during committee formation, training, site negotiation and technical launch? Contemporary records could show Rupesh's contribution without relying on later inference.

How does NPIX distinguish exchange governance from the commercial interests of entity networks? Membership rules, conflict procedures and board records would help test neutrality.

What current public measures can describe the two exchange entities without exposing sensitive operational data? Carefully defined aggregate statistics could improve transparency beyond directory row counts.

Which networks adopted route-origin validation or related practices after NPIX-supported training, and how are those practices maintained? Network-level evidence would separate enablement from deployment.

How are SANOG and npNOG programme responsibilities selected, rotated and documented? That would clarify what chair and moderator listings mean operationally.

How should the Rupesh Shrestha and Rupesh Bhakta Shrestha name variants be maintained across public records? Consistent identity handling would improve search and attribution while preventing accidental merges.

What evidence would entities use to evaluate whether NPIX still meets their operational and governance needs? The answer may differ across large providers, smaller networks, educational institutions and content operators.

These are ordinary accountability questions for a collective technical institution. They do not imply misconduct or failure. They identify where public documentation could make an already visible role chain more precise.

A bounded conclusion about exchange-community stewardship

Rupesh Shrestha's public record does not need a founder narrative to be significant. APNIC names him in the March 2002 NPIX working group. NPIX later identifies him as Managing Director in a routing-security programme. SANOG35 and npNOG10 place him in chair, moderator, update, welcome and session roles.

The sources converge on operator-community stewardship. They show a person associated with the exchange's formative group, later organisational responsibility and public technical forums. They do not show that he solely founded NPIX, owns the exchange, directs every entity or completed national routing-security deployment.

PeeringDB adds a structured picture of the institution around that role. Two NPIX exchange entities and their capture-time connection rows show a multi-entity exchange environment. The data does not establish audited traffic, service quality or Rupesh's personal responsibility for each connection.

The strongest leadership inference is procedural. Rupesh appears in named roles where local interconnection, regional knowledge exchange and national capacity building meet. Those roles create public points of responsibility even when their exact work product is not disclosed.

The source hierarchy keeps the inference honest. APNIC's article supplies the early working-group history. NPIX pages supply first-party role and programme statements. SANOG and npNOG programmes supply dated event assignments. PeeringDB and RDAP supply redacted infrastructure context, not biography.

This combination is enough for a precise conclusion: Rupesh Shrestha has a multi-source public record as an NPIX and operator-community figure whose roles connect exchange institution building, regional technical communication and routing-security enablement. It is not enough for a comprehensive biography or a claim of sole causation.

That bounded record still matters. Internet exchanges depend on people willing to maintain shared technical work across organisational boundaries. Public programmes and named roles make part of that work visible. Rupesh's record offers one view of how an exchange community can carry its institutional memory into later training and security discussions without turning collective infrastructure into a personal achievement story.