L'IETF a définit via YANG plusieurs modèles de données standards exploitables et réutilisables par les équipementiers.

Dépots de données de configurations sont des unités de configuration. Chaque configuration datastore est un ensemble de données de configuration permettant de passer d'un état initial à un état opérationnel.

Un équipement netconf a généralement plusieurs datastores:

• running (obligatoire): configuration en cours d'exécution.
• startup: Copié depuis un autre. Permet de charger une configuration spécifique au redémarrage de l'appareil.
• candidate: En cours de préparation, ne s’exécute pas

Lors de l'échange des capacités, l'équipement annonce ses configuration datastores. Changer une configuration revient donc à modifier le configuration datastore.

RFC 6241 détaille les opérations

• Verrouiller pour éviter les conflits d'édition.
• Creer un fichier de backup
• modifier la configuration, utiliser la candidate
• appliquer les modifications
• test fonctionnels via un programme/script testant le comportement.
• sauvegarder
• dévérouiller

Permet au serveur de prévenir le client de certains événements. Ne fonctionne qu' au sein d'une session netconf. Il appartient donc au client d'initialiser ce type de notification.

• Le client souscrit au service de notification du serveur en spécifiant le flux d'événements qui l'interesse.
• Si les événements se produisent, un flux XML est produit par le serveur à destination du client.

La notification n'est pas une fonctionnalité requise par la norme, l'équipement proposant ce type de service doit donc spécifiquement l'annoncer lors de l'initialisation de la connexion (messages Hello).

La sécurité des échanges du protocole netconf a fait partie intégrante des réflexions; Basée sur ssh d'autres propositions ont été faites notamment sur REST

Il existe diverses implémentations du protocole et clients netconf:

• libnetconf2 (bibliothèque C)
• ncclient (python)
• Netconfx (java)
• OpenCPE (OpenWRT support)