RE: WG Review: NETCONF Data Modeling Language (netmod)
Hi Dave, Good questions. Let me see if I can answer some of them. For perspective, I have not been involved in the developoment of any of the proposed technical directions, but I have been a general technical commentator with 16 years of IETF NM experience ;-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Wednesday, April 23, 2008 12:04 AM To: Eric Rescorla Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) Eric Rescorla wrote: Which is why it is now returned to the broader community for additional perspectives from those not already committed to a particular path Dave, my impression of your questions is that they means the broader community - those not already committed to a particular path - that EKR references. I will answer your questions from that perspective. Are they committed to doing the work? I believe the answer to this is yes. The Netconf community raised the potential need for a new data modeling language because XSD was too human-unfriendly, and both XSD and RNG lacked features needed for network management purposes. We have performed multiple comparison exercises between XSD and RNG (e.g., modeling Diffserv configuration), and all have fallen somewhat short in terms of expressing the things the OPS area feels are important to express, based on 20 years of experience with SNMP and SNMPCONF and COPS-PR, and based on experience with CLI-based configuration, and operator feedback about configuration requirements exprsessed during the IAB Network Management Workshop in 2002 an dthe subsequent world tour of NANOG, RIPE, and other operators' groups. People from the broader community (especially the APPS area) with experience in XSD and RNG came forth and prepared multiple concrete proposals to compare data modeling language approaches. All of these previous efforts have tried to be inclusive of the broader community, but many have been unofficial meetings, so the broader community may have been under-represented in some of these comparisons, but XSD and RNG have been prominent proposals. After multiple comparisons, the rough consensus of those involved was that the results remained human-unfriendly, especially the XSD format, and efforts at producing XSD schemas in WG documents had real difficulties producing valid XSD. While RNG was more human-friendly, it still was less human-friendly than desired. Unfortunately, despite going to this effort, the CANMOD BOF was prevented from actually comparing the various concrete proposals (the beauty contest), which would have shown XSD versus RNG versus YANG, relative to the stated requirements for network management purposes. Do they have their own constituency? The supporters of XSD have their own constituency. The supporters of RNG have their own constituency. The supporters of the YANG proposal have their constituency. And there are constituencies for other proposals that have not been widely accepted. Folowing a proposal for a BOF, the APPS area and some IAB members wanted some extra input on the need for a data modeling language. A design team composed of members of the OPS community and the APPS community was created to document a set of requirements. The OPS community had already been through this exercise multiple times already, as documented in multiple existing RFCs on requirementsa for configuration, and new requirements were allowed to be added to the existing requirmeents by represntatives of the various consistuencies. It was decided by the OPS ADs that concrete proposals should be prepared for presentation and comparison at a BOF to compare alternatice approaches. Multiple proposals were prepared, including proposals from OPS area and APPS area people. These proposals were prepared for a beauty contest becauser there was strong aoncensus amongst the various constituencies that we needed a data modeling language, and some felt that the existing XML-based schema languages might be sufficient. The proposals, however, reflected the fact that the existing languages fell short when trying to represent information necessary for network management **based on operator input**. Existing XML-based tools would be unable to validate the data models without having specfic extensions provided through annotations, and requiring modifications to existing tools to process those annotations. At the CANMOD BOF, the beauty contest between proposals was not allowed to be held, because certain members of the broader community insisted that the question of whether the existing languages could suffice be discussed even further, even though there was strong consensus from the OPS community (and recently from the APPS community) that the existing schema languages fall short of the requirements for network management data modeling. Following the CANMOD BOF, the constituencies from the OPS and APPS areas came
Re: WG Review: NETCONF Data Modeling Language (netmod)
Eric Rescorla wrote: At Tue, 22 Apr 2008 19:17:47 -0600, Randy Presuhn wrote: Our ADs worked very hard to prevent us from talking about technology choices at the CANMOD BOF. Our original proposal for consensus hums included getting a of sense of preferences among the various proposals. We were told we could *not* ask these questions, for fear of upsetting Eric Rescorla. Well, it's certainly true that the terms--agreed to by the IESG and the IAB--on which the BOF were held were that there not be a beauty contest at the BOF but that there first be a showing that there was consensus to do work in this area at all. I'm certainly willing to cop to being one of the people who argued for that, but I was far from the only one. If you want to blame me for that, go ahead. In any case, now that consensus to do *something* has been established it is the appropriate time to have discussion on the technology. I certainly never imagined that just because there weren't hums taken in PHL that that meant no hums would ever be taken. It's been a month since PHL. The IETF's supposed to be able to work on mailing lists between meetings, including being able to work when no WG exists - which of course means working on mailing lists that are not WG lists. I congratulate the participants who worked on the charter on managing to have the discussion and come to consensus on an approach. I think it's up to Eric to demonstrate to the IESG that there's support in the community for disagreeing with the consensus of the discussing participants. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi, I should probably just sit down and be quiet, but I have a few comments. On Tuesday 22 April 2008 23.56.40 Eric Rescorla wrote: At Tue, 22 Apr 2008 23:16:02 +0200, Bert Wijnen - IETF wrote: instead of discussing if there was consensus AT THE BOF (we all know that at this point in time we DO have consensus between all the interested WORKERS in this space, albeit that the current consensus was arrived at in further (smaller) meetings, in extensive DT work after the IETF and again after review on NGO list). Which is why it is now returned to the broader community for additional perspectives from those not already committed to a particular path Yes, indeed. It was returned to the broader community of people who care about NETCONF on March 31, three weeks ago. See http://www.ietf.org/mail-archive/web/ngo/current/msg00745.html If you don't think we have consensus, please demonstrate that by pointing out public mail (other than yours) since that time that objects to this way forward. You won't find it from the XSD people, from the RelaxNG/DSDL people, from the Kalua people, from the YANG people (that's the complete list of proposals that were shown at the CANMOD BOF) or from anyone else. In fact, ALL of those groups were involved in formulating the charter that we're now discussing. If that's not community consensus, then I have no idea what is. I propose that you list (again) your (technical) objections to the the current proposal. Sure. Based on my knowledge of modelling/protocol description languages, the techniques that Rohan described based on RNG and Schematron seemed to me quite adequate to get the job done and the relatively large baggage introduced by defining another language (YANG) which is then translated into them seems wholly unnecessary. I won't speak for Rohan or for the XSD people, but _they_ aren't objecting to this way forward, either. Again, they we were involved in the charter formulation. I appreciate that some people believe that YANG is more expressive and better suited for this particular purpose, but I didn't see any really convincing arguments of that (I certainly don't find the arguments in F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know of the complexity of designing such languages, and of their ultimate limitations and pitfalls, this seems like a bad technical tradeoff. Almost everyone else (I can't claim 100%) that's gone through this whole discussion for the last year (it all started in Prague) disagrees with you and thinks it's a reasonable way forward. If all you can tell us is that we need to spend just more cycles on re-hashing the pros and cons of many possible approaches, then I do not see the usefulness of that discussion and with become silent and leave your opion as one input to the IESG for their decision making process. Unfortunately, it's not that simple. This is precisely the technical discussion that needs to happen in a public forum, not on some design team and then presented as a fait accompli. You continue to try to make it sound like there's some little clique of people who've done something in secret and who're now ramming it down the community's collective throats. That's simply incorrect. The community has reached consensus and wants to move on. Cheers, David ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
At Wed, 23 Apr 2008 09:39:13 +0200, Harald Alvestrand wrote: I congratulate the participants who worked on the charter on managing to have the discussion and come to consensus on an approach. I think it's up to Eric to demonstrate to the IESG that there's support in the community for disagreeing with the consensus of the discussing participants. Harald, Thanks for your comments. I certainly agree that there is consensus on this approach among the proponents of the various proposals. My concern, perhaps not clearly stated, was that that consensus had not been validated with a wider community, either in the BOF or in a more public forum. Based on the discussion here, I think it's clear that in fact there is broad consensus among the people who care. I remain concerned that this is the wrong technical approach; it appears to me to be unnecessary and overcomplicated. However, it's clear that's a minority opinion, so I'll drop my objection to this charter. Best, -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Harald Alvestrand wrote: Eric Rescorla wrote: At Tue, 22 Apr 2008 19:17:47 -0600, Randy Presuhn wrote: Our ADs worked very hard to prevent us from talking about technology choices at the CANMOD BOF. Our original proposal for consensus hums included getting a of sense of preferences among the various proposals. We were told we could *not* ask these questions, for fear of upsetting Eric Rescorla. Well, it's certainly true that the terms--agreed to by the IESG and the IAB--on which the BOF were held were that there not be a beauty contest at the BOF but that there first be a showing that there was consensus to do work in this area at all. I'm certainly willing to cop to being one of the people who argued for that, but I was far from the only one. If you want to blame me for that, go ahead. In any case, now that consensus to do *something* has been established it is the appropriate time to have discussion on the technology. I certainly never imagined that just because there weren't hums taken in PHL that that meant no hums would ever be taken. It's been a month since PHL. The IETF's supposed to be able to work on mailing lists between meetings, including being able to work when no WG exists - which of course means working on mailing lists that are not WG lists. Agreed -- this also means that the 'technical approach' straw poll that did not occur in the CANMOD BoF is not really that important, since final consensus needs to be confirmed on a designated mailing list. I congratulate the participants who worked on the charter on managing to have the discussion and come to consensus on an approach. I think it's up to Eric to demonstrate to the IESG that there's support in the community for disagreeing with the consensus of the discussing participants. +1 15 person (large!) design team. 1000s of emails. Done in a month. This is more effort than most WGs can muster. Harald Andy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Rough consensus among WHOM?
Folks, The exchange over netmod was one of the more pragmatic and encouraging threads I've seen in the IETF in a very long time. I think it crystallized the core criteria that ought to drive the decision for chartering a group. Rather than filter them through my own re-wording, here are the tidbits that I think stated things quite nicely: Bert Wijnen - IETF wrote: instead of discussing if there was consensus AT THE BOF (we all know that at this point in time we DO have consensus between all the interested WORKERS in this space, Andy Bierman wrote: The 15 people on the design team represented a wide cross section of those actually interested in this work. I am among the 10 - 15 people who were not involved in the design team, but agree with the charter. That seems like a lot of consensus for this technical approach. David Partain wrote: The OM community in the IETF has been talking about this specific topic for a long time, both in official and unofficial settings. We've had many hours of meetings where people from all various viewpoints have had hashed out their differences. This all culminated during the last IETF in a rather strong sense of consensus amongst those most interested in this work that it's time to stop talking and move forward, and that YANG was the best way to do that. No, not everyone agreed, but we DO have rough consensus in the OM community and with the APPS area people who were involved that this was a reasonable approach forward. ... So, what's my point? That everyone who cares about this work and is engaged in it _does_ agree that we have consensus to move forward in this direction, that there has been public scrutiny of the proposal, and that it's time to move on. Bert Wijnen - IETF wrote: I propose that you list (again) your (technical) objections to the the current proposal. If all you can tell us is that we need to spend just more cycles on re-hashing the pros and cons of many possible approaches, then I do not see the usefulness of that discussion... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
Another +1. I don't know what to add. It is not very common that a large group of 15 persons (covering authors from all solution proposals so far) volunteer and ask for being involved in the draft charter preparation. After having hundreds of mails in the RCDML maillist and having reached a consensus for the draft charter text we came out to the NGO maillist. There were no opponents on the NGO maillist. This is also the reason why the discussion has been brought to the IETF discussion list. As I can see we did not skip any important step of the process. In all the steps there was sufficient place for discussion. And we got one step further because there was always consensus and support in the step before. As a summary: I fully support the charter proposal and the creation of the NETMOD WG. Cheers, Mehmet -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Andy Bierman Sent: Wednesday, April 23, 2008 4:45 PM To: Harald Alvestrand Cc: ietf@ietf.org Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) Harald Alvestrand wrote: Eric Rescorla wrote: At Tue, 22 Apr 2008 19:17:47 -0600, Randy Presuhn wrote: Our ADs worked very hard to prevent us from talking about technology choices at the CANMOD BOF. Our original proposal for consensus hums included getting a of sense of preferences among the various proposals. We were told we could *not* ask these questions, for fear of upsetting Eric Rescorla. Well, it's certainly true that the terms--agreed to by the IESG and the IAB--on which the BOF were held were that there not be a beauty contest at the BOF but that there first be a showing that there was consensus to do work in this area at all. I'm certainly willing to cop to being one of the people who argued for that, but I was far from the only one. If you want to blame me for that, go ahead. In any case, now that consensus to do *something* has been established it is the appropriate time to have discussion on the technology. I certainly never imagined that just because there weren't hums taken in PHL that that meant no hums would ever be taken. It's been a month since PHL. The IETF's supposed to be able to work on mailing lists between meetings, including being able to work when no WG exists - which of course means working on mailing lists that are not WG lists. Agreed -- this also means that the 'technical approach' straw poll that did not occur in the CANMOD BoF is not really that important, since final consensus needs to be confirmed on a designated mailing list. I congratulate the participants who worked on the charter on managing to have the discussion and come to consensus on an approach. I think it's up to Eric to demonstrate to the IESG that there's support in the community for disagreeing with the consensus of the discussing participants. +1 15 person (large!) design team. 1000s of emails. Done in a month. This is more effort than most WGs can muster. Harald Andy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf __ Gesendet von Yahoo! Mail. Mehr Möglichkeiten, in Kontakt zu bleiben. http://de.overview.mail.yahoo.com___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
+1 Bert Wijnen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Mehmet Ersue Verzonden: woensdag 23 april 2008 17:30 Aan: Andy Bierman; [EMAIL PROTECTED]; ietf@ietf.org Onderwerp: RE: WG Review: NETCONF Data Modeling Language (netmod) Another +1. I don't know what to add. It is not very common that a large group of 15 persons (covering authors from all solution proposals so far) volunteer and ask for being involved in the draft charter preparation. After having hundreds of mails in the RCDML maillist and having reached a consensus for the draft charter text we came out to the NGO maillist. There were no opponents on the NGO maillist. This is also the reason why the discussion has been brought to the IETF discussion list. As I can see we did not skip any important step of the process. In all the steps there was sufficient place for discussion. And we got one step further because there was always consensus and support in the step before. As a summary: I fully support the charter proposal and the creation of the NETMOD WG. Cheers, Mehmet -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Andy Bierman Sent: Wednesday, April 23, 2008 4:45 PM To: Harald Alvestrand Cc: ietf@ietf.org Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) Harald Alvestrand wrote: Eric Rescorla wrote: At Tue, 22 Apr 2008 19:17:47 -0600, Randy Presuhn wrote: Our ADs worked very hard to prevent us from talking about technology choices at the CANMOD BOF. Our original proposal for consensus hums included getting a of sense of preferences among the various proposals. We were told we could *not* ask these questions, for fear of upsetting Eric Rescorla. Well, it's certainly true that the terms--agreed to by the IESG and the IAB--on which the BOF were held were that there not be a beauty contest at the BOF but that there first be a showing that there was consensus to do work in this area at all. I'm certainly willing to cop to being one of the people who argued for that, but I was far from the only one. If you want to blame me for that, go ahead. In any case, now that consensus to do *something* has been established it is the appropriate time to have discussion on the technology. I certainly never imagined that just because there weren't hums taken in PHL that that meant no hums would ever be taken. It's been a month since PHL. The IETF's supposed to be able to work on mailing lists between meetings, including being able to work when no WG exists - which of course means working on mailing lists that are not WG lists. Agreed -- this also means that the 'technical approach' straw poll that did not occur in the CANMOD BoF is not really that important, since final consensus needs to be confirmed on a designated mailing list. I congratulate the participants who worked on the charter on managing to have the discussion and come to consensus on an approach. I think it's up to Eric to demonstrate to the IESG that there's support in the community for disagreeing with the consensus of the discussing participants. +1 15 person (large!) design team. 1000s of emails. Done in a month. This is more effort than most WGs can muster. Harald Andy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Gesendet von Yahoo! Mail. Mehr Möglichkeiten, in Kontakt zu bleiben.___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Andy Bierman wrote: I don't think a formal WG process is needed to determine that the strongest consensus exists for the approach currently outlined in the charter. The 15 people on the design team represented a wide cross section of those actually interested in this work. I am among the 10 - 15 people who were not involved in the design team, but agree with the charter. That seems like a lot of consensus for this technical approach. There seems to be a repeating pattern here where a large cross section of interested people manage to either mostly hash out their differences or are committed to grin and bear whatever the consensus is only to be thwarted by a small set of (self) appointed Internet Earls with little or no stake in the game. The IETF should be fostering getting that upfront ego-deflation, etc, done ahead of working group formation, IMO, as it makes for functional rather than dysfunctional working groups. But as it stands right now, those Internet Earls pretty much have veto power through extremely vague We are not pleased proclamations which the would-be working group has no means of clearing except for throwing open the entire can of worms again (and again and again). This really sucks and is extremely demoralizing to those who have invested more than a reasonable amount of time on the work. What's even worse is that all the exercise does is create delay since there was nothing actionable about the Proclamation in the first place. Mike, knitting ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla I propose that you list (again) your (technical) objections to the the current proposal. Sure. Based on my knowledge of modelling/protocol description languages, the techniques that Rohan described based on RNG and Schematron seemed to me quite adequate to get the job done and the relatively large baggage introduced by defining another language (YANG) which is then translated into them seems wholly unnecessary. I appreciate that some people believe that YANG is more expressive and better suited for this particular purpose, but I didn't see any really convincing arguments of that (I certainly don't find the arguments in F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know of the complexity of designing such languages, and of their ultimate limitations and pitfalls, this seems like a bad technical tradeoff. The people who believe that YANG is more expressive and better suited for this poarticular purpose include contributors to the design of SMIv2, MIB Doctors, members of the NMRG who helped develop the SMING information and data modeling language, contributors to the SMIng WG which worked on developing a proposed SMIv3 to converge the SMIv2 standard and the SPPI data modeling language standard and the NMRG SMING approach, and engineers who have multiple independent implementations of running code for Netconf data modeling. I respect their experience and combined knowledge of the complexity of designing such languages. I also respect operators' knowledge of the complexity of using such languages to actually manage networks. The NM community has been working to resolve the problem of the unsuitability of the IETF's SNMP-only approach to configuration for many years, and the NM comunity has deliberately sought out operators for feedback about what does and what doesn't work well for them in configuration data modeling. One of the major problems of designing a language for data modeling is that there are many different constituencies with very different requirements for a configuration language, which change over time, as can be seen in RFC3139 and RFC3216 and RFC3535. There are a tremendous number of potential tradeoffs to make a general-purpose language meet everybody's needs. In RFC4101 Writing Protocol Models, you argue that reviewers have only limited amounts of time and most documents fail to present an architectural model for how the protocol operates, opting instead to simply describe the protocol and let the reviewer figure it out. This is acceptable when documenting a protocol for implementors, because they need to understand the protocol in any case; but it dramatically increases the strain on reviewers. Reviewers need to get the big picture of the system and then focus on particular points. They simply do not have time to give the entire document the attention an implementor would. The NM comunity sought out multiple operator communities, and came to a similar conclusion. Operators need to review data model specifications, and quickly understand the model, often while in the middle of fire-fighting. To help address the need to quickly understand the model, the MIB Doctors have developed guidelines and templates for desecribing the data model in surrounding text. In practice, however, MIB modules are frequently distributed without the surrounding document text, and operators responding to network problems don't have time to find the right document and read it to understand the model. As a result, the NM community concluded that data models themselves need to be human readable. MIB modules, for example, are read by agent implementers, application implementers, operators, and applicatuon users (e.g., when MIB module descriptions are presented as help files). NM data models are frequently developed by enterprises to model their proprietary implementations, so it is also important that the language be easy to write correctly. XSD can be very hard to read (and even harder to write accurately). RelaxNG, possibly with Schematron, is better, but it can still be difficult to understand. YANG was written with human-readability as the highest priority. In addition, there are some specific constructs important to managing a network (and already available in MIB modules) that are not natively supported in XSD or RNG, so existing XML-based tools are incapable of writing and fully validating data models with these constructs. The NM community thinks it would be a step backwards for the IETF to ignore twenty years of consensus on the importance of these NM-related constructs, and throw these away in order to use an existing standard language that was designed for different purposes. Some major lessons we learned from SMIv1 and SMIv2 was the difficulty of building atop existing standards from other organizations with
Re: WG Review: NETCONF Data Modeling Language (netmod)
David Harrington wrote: Here are my reasons why I support the charter, which align with yours: There are multiple types of users for data models. The operators and reviewers care about the semantic model much more than the syntactic mapping. Ease of use and stability have proven to be the most important factors for NM data models. YANG provides enough semantic modeling to be useful for the NM problem at hand, and since it will be owned by the IETF, the complexity and stability will also be controllable by the IETF. By decoupling the syntactic mapping from the semantic model, the specific mapping rules can change over time as W3C standards continue to evolve, without impacting any installed base of data models. Last year XSD was the only thing. Now we seem to be dropping XSD and adopting DSDL instead. I am not convinced XSD is dead, or the DSDL will be the final answer either. But if the YANG language stays stable, I don't care. Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla I propose that you list (again) your (technical) objections to the the current proposal. Sure. Based on my knowledge of modelling/protocol description languages, the techniques that Rohan described based on RNG and Schematron seemed to me quite adequate to get the job done and the relatively large baggage introduced by defining another language (YANG) which is then translated into them seems wholly unnecessary. I appreciate that some people believe that YANG is more expressive and better suited for this particular purpose, but I didn't see any really convincing arguments of that (I certainly don't find the arguments in F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know of the complexity of designing such languages, and of their ultimate limitations and pitfalls, this seems like a bad technical tradeoff. The people who believe that YANG is more expressive and better suited for this poarticular purpose include contributors to the design of SMIv2, MIB Doctors, members of the NMRG who helped develop the SMING information and data modeling language, contributors to the SMIng WG which worked on developing a proposed SMIv3 to converge the SMIv2 standard and the SPPI data modeling language standard and the NMRG SMING approach, and engineers who have multiple independent implementations of running code for Netconf data modeling. I respect their experience and combined knowledge of the complexity of designing such languages. I also respect operators' knowledge of the complexity of using such languages to actually manage networks. The NM community has been working to resolve the problem of the unsuitability of the IETF's SNMP-only approach to configuration for many years, and the NM comunity has deliberately sought out operators for feedback about what does and what doesn't work well for them in configuration data modeling. One of the major problems of designing a language for data modeling is that there are many different constituencies with very different requirements for a configuration language, which change over time, as can be seen in RFC3139 and RFC3216 and RFC3535. There are a tremendous number of potential tradeoffs to make a general-purpose language meet everybody's needs. In RFC4101 Writing Protocol Models, you argue that reviewers have only limited amounts of time and most documents fail to present an architectural model for how the protocol operates, opting instead to simply describe the protocol and let the reviewer figure it out. This is acceptable when documenting a protocol for implementors, because they need to understand the protocol in any case; but it dramatically increases the strain on reviewers. Reviewers need to get the big picture of the system and then focus on particular points. They simply do not have time to give the entire document the attention an implementor would. The NM comunity sought out multiple operator communities, and came to a similar conclusion. Operators need to review data model specifications, and quickly understand the model, often while in the middle of fire-fighting. To help address the need to quickly understand the model, the MIB Doctors have developed guidelines and templates for desecribing the data model in surrounding text. In practice, however, MIB modules are frequently distributed without the surrounding document text, and operators responding to network problems don't have time to find the right document and read it to understand the model. As a result, the NM community concluded that data models themselves need to be human readable. MIB modules, for example, are read by agent implementers, application implementers, operators, and applicatuon users (e.g., when MIB module descriptions are presented as help files). NM data models are frequently developed by enterprises
IANA Update: Project to convert registries to XML
IETF Community: IANA is currently engaged in a project to convert the IETF related registries to XML to provide the community with multiple ways of viewing registry information. When conversion to XML is done, XML will become the source format for the registries and the current formats of html and plain text will be generated from the XML source. Stylesheets and schemas will also be made available together with XML. Users will be able to access the registries in new and useful ways, while still having the ability to see the registries in the original style. Part of the conversion requires IANA to clean-up the registries in order to fit with the XML schemas. IANA is not changing the data in the registries. IANA is cleaning up the formatting including regularizing spacing and providing consistent display of titles, references and registration procedures. For those registries that need extensive format changes, IANA will be working with the appropriate working groups and area directors to make sure that the format changes do not affect the content of the registry. Those registries that are required to be in specific formats, for example the MIBs and language subtags registries, will still be produced in the existing formats. IANA has consulted with the IETF XML directorate to make sure that the XML schemas are properly formulated. Certain decisions on schemas reflect the needs of IANA in maintaining the registries moving forward. In the coming months, cleaned-up versions of the registries will begin appearing on the IANA website. If you notice any content issues with the updated versions, or if they are not accessible, please notify IANA staff immediately and we will work with the appropriate parties to correct any inconsistencies. We look forward to providing the XML versions of the registries to better serve the community's needs. IANA will announce in advance when the registry conversion will be completed. After the conversion is complete, we intend to introduce new services such as the ability to subscribe to be notified when specific registries are updated Thank you, Michelle Cotton IANA IETF Liaison Email: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
To be clear, and for the benefit of anyone reading this who hasn't tracked attendance at the various bofs discussions, Eric was certainly not the only (then) IAB member who had issues with the proposed approach. And, due to the unavoidable collision of related sessions in our multi-tracked IETF meetings, some of us were unable to attend the CANMOD BoF in person. But, here's what I'm still missing, having caught up with this whole thread: At what point did it become unreasonable to respond to stated technical issues with (pointers to) the resolution of those issues? David Harrington's posts come closest, IMO, to providing those answers, citing the approaches used in the many and varied meetings that have occurred in the interim. I have absolutely no reason to doubt that they were comprehensive. And, given that the known issues were discussed, it would be helpful (as part of this review) to have pointers to some level of succinct summary of what the reasoning was beyond the proponents [continue to] believe this is the right way to go. I'm thinking something like one of: meeting minutes, e-mails, documents... Note that I think this issue/discussion goes well beyond this particular proposed working group. IMO, if the IETF is to be able to have focused WGs while still supporting cross-area review, we need to be diligent in reviewing, addressing, and closing issues in an open fashion. Leslie. --On April 22, 2008 11:16:02 PM +0200 Bert Wijnen - IETF [EMAIL PROTECTED] wrote: Eric, instead of discussing if there was consensus AT THE BOF (we all know that at this point in time we DO have consensus between all the interested WORKERS in this space, albeit that the current consensus was arrived at in further (smaller) meetings, in extensive DT work after the IETF and again after review on NGO list). I propose that you list (again) your (technical) objections to the the current proposal. If all you can tell us is that we need to spend just more cycles on re-hashing the pros and cons of many possible approaches, then I do not see the usefulness of that discussion and with become silent and leave your opion as one input to the IESG for their decision making process. Bert Wijnen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Eric Rescorla Verzonden: dinsdag 22 april 2008 23:14 Aan: David Partain CC: [EMAIL PROTECTED]; ietf@ietf.org Onderwerp: Re: WG Review: NETCONF Data Modeling Language (netmod) At Tue, 22 Apr 2008 23:00:53 +0200, David Partain wrote: Greetings, On Tuesday 22 April 2008 18.10.10 Eric Rescorla wrote: I object to the formation of this WG with this charter. For those who haven't been involved in the discussions to date, Eric has objected to this work from the very beginning, as far back as the first attempt to get a BOF and has continued to object since that time. As such, I'm not surprised that he objects now. Of course, since the issues I was concerned about from the very beginning remain. While there was a clear sense during the BOF that there was interest in forming a WG, there was absolutely no consensus on technical direction. Not surprisingly, I disagree. Well, it's not really like this is a matter of opinion, since the minutes are pretty clear that no consensus calls on the choice of technology were taken, only that some work in this area should move forward: http://www.ietf.org/proceedings/08mar/minutes/canmod.txt The OM community in the IETF has been talking about this specific topic for a long time, both in official and unofficial settings. We've had many hours of meetings where people from all various viewpoints have had hashed out their differences. This all culminated during the last IETF in a rather strong sense of consensus amongst those most interested in this work that it's time to stop talking and move forward, and that YANG was the best way to do that. No, not everyone agreed, but we DO have rough consensus in the OM community and with the APPS area people who were involved that this was a reasonable approach forward. So, what about this consensus thing? Sometimes ADs have to make a call, and my take is that Dan Ron did so. They asked people representing ALL of the proposals to work on a proposal for a charter. We spent a great many cycles doing exactly that. All of the proposals that you saw presented at the CANMOD BOF were very active in the charter proposal discussions and the result is the consensus of all of those people. No one got exactly what they wanted, but I think everyone felt is was a reasonable way forward. So, we have consensus amongst the various proposals' authors. The sum of all this verbiage is that, precisely as I said, there wasn't consensus at the BOF, but that there was some set of rump meetings where this compromise was hashed out. -Ekr
Re: WG Review: NETCONF Data Modeling Language (netmod)
On Wed, 23 Apr 2008 07:45:02 -0700, Eric Rescorla [EMAIL PROTECTED] said: ER I remain concerned that this is the wrong technical approach; it ER appears to me to be unnecessary and overcomplicated. However, it's ER clear that's a minority opinion, so I'll drop my objection to this ER charter. At the risk of getting things thrown at me: 1) I too actually have issues with the YANG proposal as it stands. 2) But I do think it's a slightly better starting place than the other proposals, and thus don't take issue with letting the WG start there. In particular, I strongly believe (and said this at a mic) that the result has to optimized for people that don't understand complex languages like with hard to read syntaxes like XSD, etc. I think a different language, like YANG, is necessary as the existing languages simply don't meet that goal. YANG does meet this goal better than others but I don't think it goes far enough. But I don't think the creation of the working group will mean changes can't be made to the results of a design team. Generically speaking, a design team is tasked with doing the best they can but it is still up to working group consensus to say that'll do or that'll do with these modifications. -- Wes Hardaker Sparta, Inc. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-bfd-base (Bidirectional Forwarding Detection) to Proposed Standard
The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'Bidirectional Forwarding Detection ' draft-ietf-bfd-base-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-05-07. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12097rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Proposed Standard
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Carrying Location Objects in RADIUS and Diameter ' draft-ietf-geopriv-radius-lo-19.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-05-07. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-19.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12340rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-geopriv-http-location-delivery (HTTP Enabled Location Delivery (HELD)) to Proposed Standard
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'HTTP Enabled Location Delivery (HELD) ' draft-ietf-geopriv-http-location-delivery-07.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-05-07. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16080rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-bfd-mpls (BFD For MPLS LSPs) to Proposed Standard
The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'BFD For MPLS LSPs ' draft-ietf-bfd-mpls-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-05-07. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-bfd-mpls-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11981rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-avt-rtp-hdrext (A general mechanism for RTP Header Extensions) to Proposed Standard
The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'A general mechanism for RTP Header Extensions ' draft-ietf-avt-rtp-hdrext-15.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-05-21. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-15.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13585rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-bfd-v4v6-1hop (BFD for IPv4 and IPv6 (Single Hop)) to Proposed Standard
The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'BFD for IPv4 and IPv6 (Single Hop) ' draft-ietf-bfd-v4v6-1hop-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-05-07. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12100rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-bfd-multihop (BFD for Multihop Paths) to Proposed Standard
The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'BFD for Multihop Paths ' draft-ietf-bfd-multihop-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-05-07. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12099rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF TICTOC WG Interim June 2008
The IETF TICTOC WG is holding an Interim meeting on the topics of requirements and architecture from the 16th to 18th of June 2008 in Paris, France. The meeting will start at lunch time 13.00 and continue until 18.00 on Monday the 16th. On Tuesday it will start at 9.00 and run until 18.00. On Wednesday 18th the meeting will start at 09.00 and conclude at 14.00 at the latest. The purpose of the meeting is the following: First to identify and specify the requirements that TICTOC must meet. Second to start the architectural definition of TICTOC. Participants are required to register prior to the event to ensure that the facilities can accommodate the participants and that access badges can be printed. The last day of registration is the 26th of May. Registration shall be sent to stbryant at cisco.com with the subject line TICTOC Req/Arch interim meeting indicating the participant's name and also any specific agenda requests. The meeting will most likely be held at the Cisco Office in Issy Les Moulineaux (Paris). Any questions on this event can be directed to the TICTOC WG chairs Stewart Bryant (stbryant at cisco.com) and Yaakov Stein (yaakov_s at rad.com). The TICTOC charter, and details concerning the email archive and how to subscribe can be found here: http://www.ietf.org/html.charters/tictoc-charter.html Relevant drafts are draft-bryant-tictoc-probstat-02.txt draft-stein-tictoc-modules-01.txt draft-ji-tictoc-1588-telecom-profile-framework-01.txt draft-kurtis-tictoc-itp-req-00.txt draft-zhou-tictoc-ran-sync-req-00 https://datatracker.ietf.org/drafts/draft-zhou-tictoc-ran-sync-req/ Stewart/Yaakov ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5163 on Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)
A new Request for Comments is now available in online RFC libraries. RFC 5163 Title: Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) Author: G. Fairhurst, B. Collini-Nocker Status: Standards Track Date: April 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 18 Characters: 42935 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipdvb-ule-ext-07.txt URL:http://www.rfc-editor.org/rfc/rfc5163.txt This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326. The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications. [STANDARDS TRACK] This document is a product of the IP over DVB Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5171 on Cisco Systems UniDirectional Link Detection (UDLD) Protocol
A new Request for Comments is now available in online RFC libraries. RFC 5171 Title: Cisco Systems UniDirectional Link Detection (UDLD) Protocol Author: M. Foschiano Status: Informational Date: April 2008 Mailbox:[EMAIL PROTECTED] Pages: 13 Characters: 28149 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-foschiano-udld-03.txt URL:http://www.rfc-editor.org/rfc/rfc5171.txt This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms. This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5177 on Network Mobility (NEMO) Extensions for Mobile IPv4
A new Request for Comments is now available in online RFC libraries. RFC 5177 Title: Network Mobility (NEMO) Extensions for Mobile IPv4 Author: K. Leung, G. Dommety, V. Narayanan, A. Petrescu Status: Standards Track Date: April 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 26 Characters: 56094 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mip4-nemo-v4-base-11.txt URL:http://www.rfc-editor.org/rfc/rfc5177.txt This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. [STANDARDS TRACK] This document is a product of the Mobility for IPv4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
