Ietf

I started an effort several months (years?) ago to define mappings between SNMP notifications and SYSLOG messages based on the soon to be published SYSLOG standard. Today (roughly after 7 months since I presented this work at the IETF meeting in Dublin), I got green light to post the mapping documents as IETF working group documents of the OPSAWG working group. While I believe the documents are technically complete, we will have to see what happens to them now in the IETF and I prefer to not make any predictions how long it will take until the documents hit the RFC editor queue…

The IETF week is over and one of the questions raised in one of my documents was as simple as this: What are the restrictions for valid domain names? Guess what, there is no simple answer. There are several RFCs stating some constraints on domain names and there is practical usage of domain names (not necessarily consistent with all relevant RFCs). It turns out that there is not a single specification that states all the restrictions under which valid domain names can be formed and the DNS directorate of the IETF is now helping to sort this out.

The SNMP traffic measurements and trace exchange formats document has been posted as RFC 5345.

The SNMP context engineID discovery document has been posted as [RFC 5343] (http://dx.doi.org/10.17487/RFC5343).

I am currently at the 72nd IETF meeting in Dublin. There is a mailing list for all attendees (who sign up) to discuss meeting related issues. One of the threads on this list are dietary restrictions and the many combinations that exist among the participants and the challenges of finding appropriate food. After following some of the discussion, I am wondering whether the number of people with dietary restrictions at IETF meetings is larger than normal.

Today, the formation of the NETMOD working group of the IETF has been announced. The group is chartered to develop a standard data modeling language for NETCONF. The starting point for the design is YANG. Overall, it took the YANG design team about half a year from the submission of the YANG specification to the IETF with a request for a BOF until working group formation. While the road was somewhat bumpy, the target has been reached pretty much on time.

The 71st IETF meeting is over and I have recovered from “the IETF cold”. The good news is that the NETCONF data modeling requirements discussion in the IETF is over. There is work going on to draft a charter for a NETCONF data modeling language working group and the YANG specifications are likely becoming the basis of this IETF effort. The details of course need to be further discussed and rough consensus within the IETF has to be reached. But with some luck, we will see a first IETF YANG data modeling language meeting at the 72nd IETF meeting, which takes place in Dublin end of July.

I have quite some experience with requirements discussions in the IETF and in particular with requirements discussions about network management data modeling languages and from my personal experience I can tell you that this is all a waste of time. These discussions will not bring us any closer to a decision about the direction. The only thing is that the list of requirements grows in each incarnation of this requirements collection process by some say 40 new requirements.

I have been involved in the design of a new data modeling language for the NETCONF protocol (RFC 4741) called YANG. The work was driven by a small team of energetic people from Ericsson, Juniper, and tail-f and later some others joined. The work was largely driven by considering experiences from the SMIng effort (RFC 3780) and vendor specific solutions. In addition to the language design, the YANG team has been working on implementations to make sure the language is reasonably well defined and practically useful. For some examples, tutorials, or free code, see the Yang Central web site.

The Integrated Security Model for SNMP working group of the IETF started a working group last call on the core documents. The last call runs until August 10th. Please read the documents and provide feedback to the ISMS mailing list.