Re: WG Review: NETCONF Data Modeling Language (netmod)
I echo Tom Petch's concern. Given the level of deployment success of IETF management efforts for the last 5-10 years, I'd suggest that we need both customer pull as well as technical community push for such an effort to succeed. While there have been arguments made for the latter, I don't see enough evidence of customer (in particular, operator) involvement to feel confident that the former has been addressed. David Harrington said: 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. Tom Petch said: Sounds magnificent but who are these people and where are they? I do track the YANG and NGO mailing lists and what I see there worries me. I see a significant number of questions along the lines; of what does this mean, how can this ever work, how can I do ... and the questions are all very reasonable and need answers - which they mostly get, even if they are somewhat too often along the lines of 'oh dear', or 'more work needed'. But they are the sort of questions I, for all I have done with SMI, ASN.1 and other languages, would not have thought to ask; they come from someone at the sharp end writing code for today's boxes. Yet these questions are almost all coming from just one person with a specific market place, and if he can find so many doubts and queries, how many more are there waiting to be discovered? That one person - hi, Andy! - is doing a magnificent job but for a new language to live up to its billing, we need half a dozen such people, from different parts of OM to find the holes; and I just do not see them, at least not on the YANG and NGO mailing lists. The answers, likewise, mostly come from the same three or so people; again, I am concerned that there are not more, given the claims of yang. This causes me to doubt that we, the IETF, really has the community of interest to undertake such a challenging assignment. Tom Petch ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi - From: Bernard Aboba [EMAIL PROTECTED] To: ietf@ietf.org Sent: Thursday, April 24, 2008 6:40 PM Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) I echo Tom Petch's concern. Given the level of deployment success of IETF management efforts for the last 5-10 years, I'd suggest that we need both customer pull as well as technical community push for such an effort to succeed. While there have been arguments made for the latter, I don't see enough evidence of customer (in particular, operator) involvement to feel confident that the former has been addressed. ... Whether we like it or not, the last five years have been devoted largely to NETCONF. RFC 4741 is already published on the standards track. During that time, the community has been forbidden to work on data models in the IETF. Without data models, NETCONF's utility is rather limited, to say the least. Consequently, a lack of perceived pull should hardly be surprising. The choice before us is pretty simple: - allow work to continue on standardized data models, so there will be some hope of interoperability - ignore the need, rely on the continued proliferation of proprietary approaches, and hope someone else figures out how to interoperate (though some may consider the lack of interoperability to be a sales- enhancing feature rather than a problem to be overcome) - hope some other organization will give the work a home if the people willing to do the work are not allowed to do it on IETF turf. The question now is whether the IETF wants NETCONF protocol to succeed. Yes, more operator input is desirable. But in the case of NETCONF, the protocol itself is far removed from what the operators asked for at the IAB workshop. These leaves me wondering whether more input would really change anything. Based on my understanding of the operator input at the IAB workshop, the Yang proposal, of all the ones mentioned at the CANMOD BOF, is by far the best-aligned with the concerns the operators voiced, which were, in a word, readability. (For the data itself, terms like screen scraping came up a lot.) I'm certain something better is possible, but no one has bothered to write an i-d. At some time we have to stop waiting for something better to magically appear and go with something that will be good enough that has the support of implementors. This work should have been undertaken five years ago. How much longer? Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
- Original Message - From: David Harrington [EMAIL PROTECTED] To: 'Eric Rescorla' [EMAIL PROTECTED]; 'Bert Wijnen - IETF' [EMAIL PROTECTED] Cc: ietf@ietf.org; [EMAIL PROTECTED] Sent: Wednesday, April 23, 2008 5:49 PM Subject: 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. Sounds magnificent but who are these people and where are they? I do track the YANG and NGO mailing lists and what I see there worries me. I see a significant number of questions along the lines; of what does this mean, how can this ever work, how can I do ... and the questions are all very reasonable and need answers - which they mostly get, even if they are somewhat too often along the lines of 'oh dear', or 'more work needed'. But they are the sort of questions I, for all I have done with SMI, ASN.1 and other languages, would not have thought to ask; they come from someone at the sharp end writing code for today's boxes. Yet these questions are almost all coming from just one person with a specific market place, and if he can find so many doubts and queries, how many more are there waiting to be discovered? That one person - hi, Andy! - is doing a magnificent job but for a new language to live up to its billing, we need half a dozen such people, from different parts of OM to find the holes; and I just do not see them, at least not on the YANG and NGO mailing lists. The answers, likewise, mostly come from the same three or so people; again, I am concerned that there are not more, given the claims of yang. This causes me to doubt that we, the IETF, really has the community of interest to undertake such a challenging assignment. Tom Petch Snip /Snip David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi all, On Thursday 24 April 2008 09.22.22 Tom.Petch wrote: 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. Sounds magnificent but who are these people and where are they? Do you want me to list them? If you want to know who's going to work on the topic, I suggest you first look at the list of people on http://www.ietf.org/mail-archive/web/ngo/current/msg00745.html and thereafter add people like Andy Bierman and Jürgen Schönwälder. I don't think it's particularly strange that most of the YANG traffic has been from a small group of people. We have had zero official status in the IETF up to now, although the list has been hosted on ietf.org. The document has been worked on by the people behind YANG, so they're obviously the ones who know it best. If you want numbers... the YANG gang itself is 6 people, from 4 companies and one university. The internal discussions have been intense. The charter discussion group included 11 other people representing a bunch of other interests. That group sent 575 mail messages from March 14 through April 7 and everyone participated. Do I think everyone's going to be very active in an eventual WG? No. But do I think we'll have critical mass? Absolutely. The OM community _really_ cares about this issue. Frankly, I haven't seen the kind of energy in this particular part of the IETF in many many years. We _must_ get a standard in place so we can stop answering this question, How do I model in NETCONF? with, Do whatever you want since there's no standard. I do track the YANG and NGO mailing lists and what I see there worries me. I see a significant number of questions along the lines; of what does this mean, how can this ever work, how can I do ... and the questions are all very reasonable and need answers - which they mostly get, even if they are somewhat too often along the lines of 'oh dear', or 'more work needed'. Naturally, more work is needed. That's why we want a working group... But they are the sort of questions I, for all I have done with SMI, ASN.1 and other languages, would not have thought to ask; they come from someone at the sharp end writing code for today's boxes. Yet these questions are almost all coming from just one person with a specific market place, and if he can find so many doubts and queries, how many more are there waiting to be discovered? That one person - hi, Andy! - is doing a magnificent job but for a new language to live up to its billing, we need half a dozen such people, from different parts of OM to find the holes; and I just do not see them, at least not on the YANG and NGO mailing lists. There are at least three NETCONF implementers on the list (in the YANG gang), plus a large cross-section of the OM community at the IETF. See the numbers above. Perhaps I'm thick, but I don't see how this _doesn't_ qualify as critical mass. The answers, likewise, mostly come from the same three or so people; again, I am concerned that there are not more, given the claims of yang. This causes me to doubt that we, the IETF, really has the community of interest to undertake such a challenging assignment. And, given the above, I have no doubt whatsoever. Cheers, David ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
I echo Tom Petch’s concern. Given the level of deployment success of new IETF management efforts for the last 5-10 years, I’d suggest that we need both customer “pull” as well as technical community “push” for such an effort to succeed. While there have been arguments made for the latter, I don’t see enough evidence of customer (in particular, operator) involvement to feel confident that the former has been addressed. David Harrington said: “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.” Tom Petch said: “Sounds magnificent but who are these people and where are they? I do track the YANG and NGO mailing lists and what I see there worries me. I see a significant number of questions along the lines; of what does this mean, how can this ever work, how can I do ... and the questions are all very reasonable and need answers - which they mostly get, even if they are somewhat too often along the lines of 'oh dear', or 'more work needed'. But they are the sort of questions I, for all I have done with SMI, ASN.1 and other languages, would not have thought to ask; they come from someone at the sharp end writing code for today's boxes. Yet these questions are almost all coming from just one person with a specific market place, and if he can find so many doubts and queries, how many more are there waiting to be discovered? That one person - hi, Andy! - is doing a magnificent job but for a new language to live up to its billing, we need half a dozen such people, from different parts of OM to find the holes; and I just do not see them, at least not on the YANG and NGO mailing lists. The answers, likewise, mostly come from the same three or so people; again, I am concerned that there are not more, given the claims of yang. This causes me to doubt that we, the IETF, really has the community of interest to undertake such a challenging assignment. Tom Petch”___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
official minutes for that discussion. I personally arrived about 45 minutes late to the meeting. There were representatives from most of the constituencies that had prepared concrete proposals. They had already agreed to a strawman approach starting with YANG as a human-friendly DML with a mapping to one of the XML schema langauges for machine-readability. (This was consistent with the mood of the OPS Area open meeting the day before.) It was decided to have the rcdml design team, plus the new Netconf chairs, develop a proposed charter. The discussions of the charter proposal were held on the rcdml mailing list, whose archives can be found at http://www.partain.se/mailman/listinfo/rcdml. This mailing list had respresentatives from each of the constituencies that prepared proposals for the beauty contest. The design team posted the proposed charter to the NGO mailing list for review http://www.ietf.org/mail-archive/web/ngo/current/msg00745.html. The design team proposal is of course no better than any other proposal, so it was posted to NGO for further community discussion. Apr08: The IESG secretary announced a WG review for Netconf Data Modeling Language to the IETF mailing list. I hope this is helpful. Let me kniw if I can help further. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla Sent: Tuesday, April 22, 2008 5:18 PM To: Bert Wijnen - IETF Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) At Tue, 22 Apr 2008 23:10:53 +0200, Bert Wijnen - IETF wrote: W.r.t. All this is great stuff, but it all happened after the BOF, so you can't reasonably claim that it represents BOF consensus. And since BOFs are our primary mechanism for open, cross area assessment for WG formation, I don't think it's accurate to suggest that this is anywhere as near as open as actually having the discussion in the BOF and gettting consensus, nor is it a substitute for that. I do not think that forming a WG MANDATES a BOF. Several WGs have been formed (in the past) without a BOF. So pls do not depict a story as if a BOF is the only way how we reach consensus in IETF on teh question of forming a WG or not. Yes, but when you have a BOF which doesn't come to consensus on a technical direction, which is then shortly followed by a proposed charter which *does* specify a technical direction, I think that's a somewhat different story. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
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
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
Re: WG Review: NETCONF Data Modeling Language (netmod)
I object to the formation of this WG with this charter. 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. Rather, a number of proposals were presented, but no strawpoll, hum, or sense of the room was taken, nor, as far as I can determine, has there been any such consensus call been taken on any list I'm aware of. This wasn't an accident--the BOF was explicitly intended only to determine whether some work in this area should proceed, not to select a technical approach. I understand that an approach like this was proposed in the OPSAREA meeting by Chris Newman and then that there was a breakout meeting where it was discussed further. The minutes don't record any consensus call on this combined direction (only strawpolls on the individual proposals), and even if such a consensus call had been held, the OPSAREA meeting would not be the appropriate place for it: this discussion needs to happen in either the BOF (to allow cross-area review) or in the designated WG, when it is formed. Accordingly, if this WG is to be formed, the entire section (and corresponding milestones) which specifies the technology needs to be removed. Rather, the first work item should be to select a technical approach. -Ekr NETCONF Data Modeling Language (netmod) Last modified: 2008-04-10 Current Status: Proposed Working Group Chair(s): TBD Operations and Management Area Director(s): Dan Romascanu dromasca at avaya.com Ronald Bonica rbonica at juniper.net Mailing Lists: General Discussion: ngo at ietf.org Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a human-friendly modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements) are not relevant for translation from SMIv2 to YANG. YANG is also permitted to introduce constructs that cannot be expressed in SMIv2. However, all basic types that can be represented in SMIv2 must be expressible in YANG. Initial deliverables are below. The working group may choose to combine multiple deliverables into a single document where deemed appropriate. 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) 2. The YANG data modeling language and semantics (proposed standard) 3. Mapping rules of YANG to XML instance data in
Re: WG Review: NETCONF Data Modeling Language (netmod)
Eric Rescorla wrote: I object to the formation of this WG with this charter. 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. Rather, a number of proposals were presented, but no strawpoll, hum, or sense of the room was taken, nor, as far as I can determine, has there been any such consensus call been taken on any list I'm aware of. This wasn't an accident--the BOF was explicitly intended only to determine whether some work in this area should proceed, not to select a technical approach. I understand that an approach like this was proposed in the OPSAREA meeting by Chris Newman and then that there was a breakout meeting where it was discussed further. The minutes don't record any consensus call on this combined direction (only strawpolls on the individual proposals), and even if such a consensus call had been held, the OPSAREA meeting would not be the appropriate place for it: this discussion needs to happen in either the BOF (to allow cross-area review) or in the designated WG, when it is formed. I believe there was consensus in the CANMOD BoF that the requirements were sufficiently understood, and the purpose of that BoF had been fulfilled. After the CANMOD BoF, a 15 person design team was formed, which reached consensus on a technical approach, embodied in the charter text. There was also unanimous agreement on the charter, outside the design team (on the NGO mailing list). Accordingly, if this WG is to be formed, the entire section (and corresponding milestones) which specifies the technology needs to be removed. Rather, the first work item should be to select a technical approach. I thought the charter text did specify a technical approach, which is to utilize YANG as a high-level DML and map YANG constructs to DSDL and XSD. Can you explain this work item further? -Ekr Andy NETCONF Data Modeling Language (netmod) Last modified: 2008-04-10 Current Status: Proposed Working Group Chair(s): TBD Operations and Management Area Director(s): Dan Romascanu dromasca at avaya.com Ronald Bonica rbonica at juniper.net Mailing Lists: General Discussion: ngo at ietf.org Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a human-friendly modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements)
RE: WG Review: NETCONF Data Modeling Language (netmod)
Eric REALLY... I heard during that BOF that there was consensus to start the work. I also saw that quite a few liked the YANG proposal, and several wanted to have mappings to either XSD or RELAX or DSDL. The smaller meetings that happened after the NOF, included people from all of the proposals that were on the table, including people who were in teh Design Team for the requirements. We had fruitfull discussions that converged onto a single approach. We then got all the people from the various proposls together on the rdcml mailing list (the one that was used by the requirements design team), and we had a 2 week long discussion with multiple hundereds of emails and opinions, and again, we converged to a common and acceptable draft WG charter. That draft WG charter was then put to the NGO mailing list were we had further discussion with various other people. Again we seem to have consensus. Several non-original-netconf people are on that mailing list, as a result of the BOF discussions we have had in the past thow IETF meetings. Then, Dan brought it to IESG, and the IESG agreed to send the WG proposal out for IETF Wide review. That is where we are now, and sure you can vent your opinion, but claiming (or accusing us) that there was no wide discussion or that there is no consensus at all and that there were/are just 4 different groups with conflicting proposals does not seem valid to me. Further, the change you propose to the WG charter, could be done,. and then in the first WG session we could declare victory for the milestone you want. I believe that virtually all of the interested people were involved in the discussion sofar. So I do not see why we would need long in a newly formed WG to come to the same conclusion again. But if we do what you propose, then we will consume again more cycles of IESG/IAB and the IETF at large, because they will have to look once more at the WG rechartering in 3 months time. Bert Wijnen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Eric Rescorla Verzonden: dinsdag 22 april 2008 18:10 Aan: ietf@ietf.org; [EMAIL PROTECTED] Onderwerp: Re: WG Review: NETCONF Data Modeling Language (netmod) I object to the formation of this WG with this charter. 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. Rather, a number of proposals were presented, but no strawpoll, hum, or sense of the room was taken, nor, as far as I can determine, has there been any such consensus call been taken on any list I'm aware of. This wasn't an accident--the BOF was explicitly intended only to determine whether some work in this area should proceed, not to select a technical approach. I understand that an approach like this was proposed in the OPSAREA meeting by Chris Newman and then that there was a breakout meeting where it was discussed further. The minutes don't record any consensus call on this combined direction (only strawpolls on the individual proposals), and even if such a consensus call had been held, the OPSAREA meeting would not be the appropriate place for it: this discussion needs to happen in either the BOF (to allow cross-area review) or in the designated WG, when it is formed. Accordingly, if this WG is to be formed, the entire section (and corresponding milestones) which specifies the technology needs to be removed. Rather, the first work item should be to select a technical approach. -Ekr NETCONF Data Modeling Language (netmod) Last modified: 2008-04-10 Current Status: Proposed Working Group Chair(s): TBD Operations and Management Area Director(s): Dan Romascanu dromasca at avaya.com Ronald Bonica rbonica at juniper.net Mailing Lists: General Discussion: ngo at ietf.org Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a human-friendly modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point
Re: WG Review: NETCONF Data Modeling Language (netmod)
At Tue, 22 Apr 2008 10:08:49 -0700, Andy Bierman wrote: Eric Rescorla wrote: I object to the formation of this WG with this charter. 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. Rather, a number of proposals were presented, but no strawpoll, hum, or sense of the room was taken, nor, as far as I can determine, has there been any such consensus call been taken on any list I'm aware of. This wasn't an accident--the BOF was explicitly intended only to determine whether some work in this area should proceed, not to select a technical approach. I understand that an approach like this was proposed in the OPSAREA meeting by Chris Newman and then that there was a breakout meeting where it was discussed further. The minutes don't record any consensus call on this combined direction (only strawpolls on the individual proposals), and even if such a consensus call had been held, the OPSAREA meeting would not be the appropriate place for it: this discussion needs to happen in either the BOF (to allow cross-area review) or in the designated WG, when it is formed. I believe there was consensus in the CANMOD BoF that the requirements were sufficiently understood, and the purpose of that BoF had been fulfilled. Agreed. After the CANMOD BoF, a 15 person design team was formed, which reached consensus on a technical approach, embodied in the charter text. There was also unanimous agreement on the charter, outside the design team (on the NGO mailing list). Neither of these has any formal standing. The precise reason we have BOFs is to have these discussions in person at IETF. Accordingly, if this WG is to be formed, the entire section (and corresponding milestones) which specifies the technology needs to be removed. Rather, the first work item should be to select a technical approach. I thought the charter text did specify a technical approach, which is to utilize YANG as a high-level DML and map YANG constructs to DSDL and XSD. Yes, that's what I'm objecting to, since that's far from the only technical approach. For instance, one could just use DSDL or XSD without YANG. Can you explain this work item further? Uh, have a charter that doesn't specify the technical approach and then have an open discussion in the WG meetings followed by selection of a technical approach. Compare, for instance, the process that P2PSIP is engaging in now. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi - From: Eric Rescorla [EMAIL PROTECTED] To: ietf@ietf.org; [EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 10:10 AM Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) ... Accordingly, if this WG is to be formed, the entire section (and corresponding milestones) which specifies the technology needs to be removed. Rather, the first work item should be to select a technical approach. ... I think the simplest answer would be to simply publish the work that's already been done and not bother with the IETF. There is simply no value in wasting electrons on battles like this. Sure, some opportunities for technological refinement and building a stronger community consensus migh tbe lost, but that might be a small price to pay in comparison to the time and energy required for all this pointless hoop-jumping. Particularly since the proposed/ draft/standard distinction has become so meaningless, it makes more sense to just publish the spec and ignore the peanut gallery. Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
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. 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. 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. Thereafter, the WG charter proposal was published on the NGO (netconf goes on) mailing list, which is a list used for non WG-related discussions but tightly coupled to NETCONF. APPS area people were, of course, also involved. The proposed charter was published well in advance of discussion within the IESG. There were some requests for changes (which happened), but no one jumped up and said, NO WAY! So, I certainly think that indicates we have consensus in the NETCONF and APPS communities. Then the IESG discussed the proposed charter and that's where this discussion comes up. Other than your mail, there's been zero (public?) objection to forming this working group. 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. I am completely convinced that more BOFs are not going to change any of this. It's time to move on and get some work done. Cheers, David ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
At Tue, 22 Apr 2008 19:14:10 +0200, Bert Wijnen - IETF wrote: Eric REALLY... Yes, really. I heard during that BOF that there was consensus to start the work. I also saw that quite a few liked the YANG proposal, and several wanted to have mappings to either XSD or RELAX or DSDL. I don't remember any consensus call, hum, or anything else being taken on protocol selection. Rather, I remember there being presentations with questions and minimal discussion. The smaller meetings that happened after the NOF, included people from all of the proposals that were on the table, including people who were in teh Design Team for the requirements. We had fruitfull discussions that converged onto a single approach. We then got all the people from the various proposls together on the rdcml mailing list (the one that was used by the requirements design team), and we had a 2 week long discussion with multiple hundereds of emails and opinions, and again, we converged to a common and acceptable draft WG charter. That draft WG charter was then put to the NGO mailing list were we had further discussion with various other people. Again we seem to have consensus. Several non-original-netconf people are on that mailing list, as a result of the BOF discussions we have had in the past thow IETF meetings. All this is great stuff, but it all happened after the BOF, so you can't reasonably claim that it represents BOF consensus. And since BOFs are our primary mechanism for open, cross area assessment for WG formation, I don't think it's accurate to suggest that this is anywhere as near as open as actually having the discussion in the BOF and gettting consensus, nor is it a substitute for that. Further, the change you propose to the WG charter, could be done,. and then in the first WG session we could declare victory for the milestone you want. I believe that virtually all of the interested people were involved in the discussion sofar. So I do not see why we would need long in a newly formed WG to come to the same conclusion again. Perhaps that's true, but I don't see that that's an argument against actually running an open process rather than declaring a winner in advance and asking the IETF to ratify it. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
On Tuesday 22 April 2008 23.06.57 Eric Rescorla wrote: Perhaps that's true, but I don't see that that's an argument against actually running an open process rather than declaring a winner in advance and asking the IETF to ratify it.' Hi, There seems to be an underlying argument that we've somehow been doing cloak dagger backroom cigar-smokin' stuff. That's not true at all, which I hope my previous response adequately demonstrated. Cheers, David ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
W.r.t. All this is great stuff, but it all happened after the BOF, so you can't reasonably claim that it represents BOF consensus. And since BOFs are our primary mechanism for open, cross area assessment for WG formation, I don't think it's accurate to suggest that this is anywhere as near as open as actually having the discussion in the BOF and gettting consensus, nor is it a substitute for that. I do not think that forming a WG MANDATES a BOF. Several WGs have been formed (in the past) without a BOF. So pls do not depict a story as if a BOF is the only way how we reach consensus in IETF on teh question of forming a WG or not. Bert ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
On Tuesday 22 April 2008 23.14.01 Eric Rescorla wrote: 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. Greetings, And what will be gained by forcing us to jump through more hoops? You seem to dismiss the consensus because it didn't happen the way you think it should. How does it make it less the consensus? Cheers, David ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Randy Presuhn wrote: Hi - From: Eric Rescorla [EMAIL PROTECTED] To: ietf@ietf.org; [EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 10:10 AM Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) ... Accordingly, if this WG is to be formed, the entire section (and corresponding milestones) which specifies the technology needs to be removed. Rather, the first work item should be to select a technical approach. ... I think the simplest answer would be to simply publish the work that's already been done and not bother with the IETF. There is simply no value in wasting electrons on battles like this. Sure, some opportunities for technological refinement and building a stronger community consensus migh tbe lost, but that might be a small price to pay in comparison to the time and energy required for all this pointless hoop-jumping. Particularly since the proposed/ draft/standard distinction has become so meaningless, it makes more sense to just publish the spec and ignore the peanut gallery. This 'simple' approach doesn't move standardized network configuration along at all, so it is not my first choice. IMO, there is strong community consensus for the charter as it is currently written. There are several technical approaches, such as 'continue to write data models in XSD' which are technically viable, but have no community consensus at all. 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. Randy Andy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
At Tue, 22 Apr 2008 23:10:53 +0200, Bert Wijnen - IETF wrote: W.r.t. All this is great stuff, but it all happened after the BOF, so you can't reasonably claim that it represents BOF consensus. And since BOFs are our primary mechanism for open, cross area assessment for WG formation, I don't think it's accurate to suggest that this is anywhere as near as open as actually having the discussion in the BOF and gettting consensus, nor is it a substitute for that. I do not think that forming a WG MANDATES a BOF. Several WGs have been formed (in the past) without a BOF. So pls do not depict a story as if a BOF is the only way how we reach consensus in IETF on teh question of forming a WG or not. Yes, but when you have a BOF which doesn't come to consensus on a technical direction, which is then shortly followed by a proposed charter which *does* specify a technical direction, I think that's a somewhat different story. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
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 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
Well said Andy. And I support the charter as well! Bert Wijnen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Andy Bierman Verzonden: dinsdag 22 april 2008 23:14 Aan: Randy Presuhn CC: ietf@ietf.org Onderwerp: Re: WG Review: NETCONF Data Modeling Language (netmod) Randy Presuhn wrote: Hi - From: Eric Rescorla [EMAIL PROTECTED] To: ietf@ietf.org; [EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 10:10 AM Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) ... Accordingly, if this WG is to be formed, the entire section (and corresponding milestones) which specifies the technology needs to be removed. Rather, the first work item should be to select a technical approach. ... I think the simplest answer would be to simply publish the work that's already been done and not bother with the IETF. There is simply no value in wasting electrons on battles like this. Sure, some opportunities for technological refinement and building a stronger community consensus migh tbe lost, but that might be a small price to pay in comparison to the time and energy required for all this pointless hoop-jumping. Particularly since the proposed/ draft/standard distinction has become so meaningless, it makes more sense to just publish the spec and ignore the peanut gallery. This 'simple' approach doesn't move standardized network configuration along at all, so it is not my first choice. IMO, there is strong community consensus for the charter as it is currently written. There are several technical approaches, such as 'continue to write data models in XSD' which are technically viable, but have no community consensus at all. 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. Randy Andy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi all, On Tuesday 22 April 2008 23.14.03 Andy Bierman wrote: IMO, there is strong community consensus for the charter as it is currently written. There are several technical approaches, such as 'continue to write data models in XSD' which are technically viable, but have no community consensus at all. 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. Absolutely. Well said. David ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
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 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. 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. That said, I think I've stated my position as best I can and that while I understand yours, you and I just disagree about what the IESG should do, so I'll take your advice to become silent at this point. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi - 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. (It's unclear to me why his perspectives on configuration management information models should be subject to special consideration, while the folk who have been doing active work and real products in this area over the last two decades are largely ignored.) The people from the various design teams put a great deal of time and energy into understanding each others' proposals and the tradeoffs. The standardazition of a modeling environment for NECONF should have been completed literally five years ago. The notion that further delay is desirable is simply silly. That said, I do agree with the others regarding the charter proposal. While it's probably not exactly what anyone wanted, it does represent something just about everyone who is actually doing work in this area could not just live with, but actually support. Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
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 unclear to me why his perspectives on configuration management information models should be subject to special consideration, while the folk who have been doing active work and real products in this area over the last two decades are largely ignored.) Given that the BOF was in fact held and the WG is now being proposed, largely ignored isn't quite the way I would characterize the situation. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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 Are they committed to doing the work? Do they have their own constituency? Since the topic is not new, where have they been and why have they not developed their own group consensus? Rather than perspectives where are the technical concerns that Bert asked about? 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)
Hi - From: Dave Crocker [EMAIL PROTECTED] To: Eric Rescorla [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Tuesday, April 22, 2008 10:03 PM Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) ... Are they committed to doing the work? The bulk of the work has been done (or close to it) for quite some time. Ideally, it would have been done *before* the NETCONF protocol was cast in concrete, but the NETCONF working group was not allowed to define a modeling approach before finishing a protocol. Without data models, the protocol is useless. Consequently, there are already numerous vendor-specific ways of handling modeling, and even multiple approaches showing up some companies. Not good. Do they have their own constituency? All the major players in the devlopment of the NETCONF protocol, as far as I know. Since the topic is not new, where have they been and why have they not developed their own group consensus? Previous requests for a BOF like the one held in Philadelphia were denied. The various design teams have considerable common ground, and the consensus of the folks who are actually doing work is in my opinion pretty accurately reflected in the charter proposal. Rather than perspectives where are the technical concerns that Bert asked about? As I see it, the key technical issues are these: 1) Is there a need for a domain-specific language for network configuration management data modeling? Experience in the field gives an unequivocal yes. GDMO, SMI, and CIM are a few examples of how folks have dealt with the shortcomings of the general-purpose tools available over the years. General-purpose modeling languages are both too much and too little, particularly with regard to issues of inter-version compatibility of models and interoperability. Even if a language can represent an important semantic, there's still the question of whether that particular solution is compact and intuitive. With some, to represent common constraints like uniqueness the designer had to resort to the equivalent of assembler language. 2) Does it make sense to use an XML-based syntax for the human-friendly representation of data models? For industrial-strength models the answer becomes more and more no as the model becomes larger and more semantically rich. This is not a question of expressive power. It's a question of providing a way to support development of *readable* standardized data models for NETCONF. Forgive my impatience. We went through this same debate twenty years ago regarding ASN.1 and GDMO, and only slightly later in de-coupling SNMP SMI from ASN.1 The acronyms may have changed, but the answers haven't. Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
--On April 15, 2008 13:30:01 -0700 IESG Secretary [EMAIL PROTECTED] wrote: NETCONF Data Modeling Language (netmod) I support the creation of this WG. 2. The YANG data modeling language and semantics (proposed standard) ... 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). A great deal of effort has been put into designing standard XML data modeling languages over many years and given that both DTD and XML Schema have significant weaknesses (particularly in the area of extensibility), a DML for XML is clearly difficult and requires special expertise. (5) is critical to demonstrating that YANG has learned from the mistakes of past XML-DMLs with respect to extensibility and other areas. The simpler (5) happens to be, the more confident I will become that YANG is following best practices for XML DMLs. 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) If 5 is as simple as I think it should be, then I suspect there will be little semantic difference between 4 5 and much additional utility in 5. I'd prefer if the WG was free to drop work item 4 in the event I'm correct. If 2 provides the human-friendly form and 5 provides the form that best leverages existing standard XML tools and parsers then I see no value in 4 which is both less human-friendly than 2 and less XML-tool-friendly than 5. In the event I'm wrong and there are significant semantic differences between 2/4 and 5 that are well justified, then I don't object to continued work on 4. I suggest adding a sentence to the charter: In the event work items 4 and 5 are semantically similar, the WG may choose to omit work item 4. I'm interested in other opinions on this topic. - Chris ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [NGO] WG Review: NETCONF Data Modeling Language (netmod)
Chris Newman writes: The simpler (5) happens to be, the more confident I will become that YANG is following best practices for XML DMLs. My guess is the opposite: many of the more useful features of XSD and DSDL require distinct and uncomfortable layout of the schema material. For example, the XSD substitution group mechanism allows for extensibility, but requires the schema to include substitution group information pervasively throughout the schema and to make a very shallow hierarchy through the use of types and indirection. This gives a format that I believe non-validating consumers of the schema will find difficult to read and use. By contrast, YIN is a straight-forward conversion of the textual data from a YANG module into an XML format that can be easily and directly used by the consumer. The conversion is trivia and the information is in a state identical to the YANG module's layout. The encoding is changed (to XML) but the content is untouched. So if (5) is simple, we've either chosen not to use significant but uncomfortable features in the low-level output language, or we've lost the conciseness, hierarchical view, and other high-level features that makes YANG worthwhile. This isn't to say that (5) shouldn't be fairly mechanical, something that a perl or xslt script could handle, but it shouldn't be called simple, nor should the complexity of that transformation a basis for judging YANG. Thanks, Phil ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
