In a previous blog post (which I wrote about three years ago), I wrote about the consequences of adding version numbers to the YANG naming scheme. The take away message was that doing so has major consequences also for the protocols that are used to manipulate YANG defined data. Meanwhile, a concrete proposal has appeared to change the YANG versioning rules and to introduce semantic version numbers. Hence it is a good time to look at this topic again.
I am following up on my previous post on this topic, which was focusing on issues related to the timely development of YANG modules. There are other key factors that determine the speed in which work completes and that are often ignored in the IETF when people discuss work to be taken on and define milestones.
A big part is the management of the human resources. Yes, this may sound strange give that the IETF is a volunteer organization and hence does not directly “control” human resources.
The IETF is slow. The IETF is too slow. We know that, no news here.
There was a discussion today about this topic in the OPS area meeting of the 99th IETF meeting, mostly driven by the fact that the networking industry (not just the IETF) is hit by a wave of YANG modules. Some ideas were presented to help organize this process. I personally do not think the IETF has a problem due to a lack of version numbers nor do I think the IETF has a real problem with format conversions of artefacts.
The IETF is meeting in Chicago this week and I am participating remotely via Meetecho. The remote participation service is improving every IETF it seems, saving me from a lot of long distance traveling hassle during the semester. While the people providing the remote participation service do a wonderful job, I believe a big part of this working well for me is that I know many of the regular contributors good enough from prior meetings I attended in person so that I can extract many soft signals just from the voice stream.
I have accepted an invitation to co-chair the [NETMOD Working Group] (https://datatracker.ietf.org/wg/netmod/) in the Operations and Management Area of the IETF. Almost exactly five years ago, I have been in a similar situation when I was asked to co-chair the ISMS Working Group in the Security Area of the IETF. I am still co-chairing ISMS - lets see how long my engagement with NETMOD is going to last…
The IETF has just opened a store where you can buy official IETF logo wear. This is an interesting new move towards IETF sponsorship since some of the money of each item goes to the IETF. I have no clue how much money this brings, but surely there are a few observations I like to share:
The shop, likely located in the UK, knows shipping rates to Australia, Canada, the United Kingdom, the USA and of course worldwide.
At the 81st IETF in Quebec, a new working group was formed to work on standards for home networks. During the kickoff meeting, a number of talks were delivered depicting a future where homes have an integrated network infrastructure comprising of several sub-networks (IPv6 of course ;-) interconnected by several routers and supported by multiple uplinks. Furthermore, a number of firewalls will be present to provide separation between the office network, the entertainment network, the kid’s network, the utility network, the home automation network, the health monitoring network, etc.
Today, an Internet-Draft (I-D) was posted with the goal to clarify how to cite Requests for Comments (RFCs). The suggested BiBTeX format is relatively close to what I happen to use for about 15 years. But the final word, of course, has not been spoken about this and there are some interesting questions one can ask. For example, since RFCs fail to represent author names properly (unless your parents were wise enough to give you a name that is 7-bit US ASCII compatible), the question arises whether a citation in publications that do allow the proper representation of names (almost all journals and conferences) MAY use a person’s native spelling of his name or whether one MUST use the spelling in the published RFC.
Two new RFCs have just been posted: RFC 5675 defines how to represent SNMP notifications as structured SYSLOG messages and RFC 5676 defines a MIB module for representing structured SYSLOG messages as SNMP MIB objects and SNMP notifications.
The specification of a transport subsystem for the Simple Network Management Protocol (SNMP) has been posted as RFC 5590.