b'\n_START_ARTICLE_\nNETCONF\n_START_SECTION_\nHistoria\n_START_PARAGRAPH_\nEl IETF desarroll\xc3\xb3 el Protocolo de Administraci\xc3\xb3n de Red Sencillo (SNMP) a fines de los 80s y  result\xc3\xb3 ser un protocolo de administraci\xc3\xb3n de red muy popular. En la parte temprana del siglo XXI  se hace aparente que a pesar de lo que se intent\xc3\xb3 originalmente, SNMP no estaba siendo utilizado para configurar equipamiento de red, sino que principalmente era utilizado para monitoreo de red. En junio del 2002, el Directorio de Arquitectura del Internet y algunos miembros claves de la comunidad de administraci\xc3\xb3n de red del IETF se reunieron con operadores de red para discutir la situaci\xc3\xb3n. Los resultados de esta reuni\xc3\xb3n se documentaron en [rfc:3535 RFC 3535.] Result\xc3\xb1o que los operadores principalmente utilizaban Interfaces de L\xc3\xadnea de Orden propietarias (CLI) para configurar sus dispositivos. Esto ten\xc3\xada una cantidad de caracter\xc3\xadsticas que a los operadores les gustaba, incluyendo el hecho que estaba basado en texto, en oposici\xc3\xb3n al SNMP que estaba codificado en BER. Adem\xc3\xa1s, muchos vendedores de equipamiento no proporcionaban la opci\xc3\xb3n para configurar completamente sus dispositivos v\xc3\xada SNMP. Aun cuando a los operadores generalmente les gustaba escribir scripts para facilitar la configuraci\xc3\xb3n de sus cajas, encontraban que el CLI SNMP era insuficiente en varios temas. A\xc3\xban m\xc3\xa1s importante era la naturaleza imprevisible del resultado. El contenido y formato del resultado era propenso a cambiar de maneras imprevisibles._NEWLINE_M\xc3\xa1s o menos al mismo tiempo, Juniper Networks hab\xc3\xada tomado una aproximaci\xc3\xb3n de administraci\xc3\xb3n de red utilizando XML. Esto se comparti\xc3\xb3 con IETF y luego se comparti\xc3\xb3 con el resto de la comunidad. En conjunto, estos dos acontecimientos dirigieron el IETF en mayo 2003 a la creaci\xc3\xb3n del NETCONF grupo laborable. Este grupo de trabajo fue comisionado para trabajar en un protocolo de configuraci\xc3\xb3n de la red, el cual  alineara mejor las necesidades de los operadores de red y de los vendedores de equipamiento. La primera versi\xc3\xb3n del protocolo base de NETCONF fue publicado como RFC 4741 en diciembre del 2006. Varias extensiones se publicaron en a\xc3\xb1os subsiguientes (notificaciones en RFC 5277 en julio del 2008, cierres parciales en RFC 5717 en diciembre del 2009, valores por defecto en RFC 6243 en junio del 2011, notificaciones de sistema en RFC 6470 en febrero del 2012, control de acceso en RFC 6536 en marzo de 2012). Una versi\xc3\xb3n revisada del protocolo base de NETCONF fue publicado como RFC 6241 en junio 2011.\n_START_SECTION_\nContenido\n_START_PARAGRAPH_\nEl contenido de las operaciones de NETCONF es un XML bien formado. La mayor\xc3\xada de contenido est\xc3\xa1 relacionado a administraci\xc3\xb3n de red. Posteriormente se agreg\xc3\xb3 soporte para codificar en Notaci\xc3\xb3n de Objeto del Javascript (JSON) tambi\xc3\xa9n._NEWLINE_El grupo de trabajo NETMOD ha completado trabajo para definir un lenguaje de modelamiento "amistoso para el humano" para definir la sem\xc3\xa1ntica de datos operacionales, datos de configuraci\xc3\xb3n, notificaciones y operaciones, llamado YANG.  YANG est\xc3\xa1 definido en RFC 6020 (versi\xc3\xb3n 1) y RFC 7950 (versi\xc3\xb3n 1.1), y est\xc3\xa1 acompa\xc3\xb1ado por el "Tipos de Datos comunes YANG" definidos en RFC 6991._NEWLINE_Durante el verano de 2010, el grupo de trabajo NETMOD fue re-comisionado para trabajar en modelos de configuraci\xc3\xb3n del n\xc3\xbacleo (sistema, interfaz, y encaminamiento) as\xc3\xad como trabajar en compatibilidad con el lenguaje de modelamiento SNMP.'