Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Apr 2008 09:10:10 -0700

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 NETCONF
> (proposed standard)
> 
> 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)
> 
> 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).
> 
> 6. A standard type library for use by YANG (proposed standard)
> 
> Goals and Milestones:
> 
> Jun 2008 - All _individual_ drafts available that will be used as
> input into the WG documents (draft-bjorklund-yang, architecture
> draft, YIN draft, YANG standard library draft, DSDL mapping rules
> draft)
> 
> Aug 2008 - Initial set of WG drafts: architecture, YANG, YIN,
> YANG standard library, DSDL mapping rules (if there is one/more
> individual draft), based on WG decisions in Dublin
> 
> Sep 2008 - Initial DSDL mapping rules document
> 
> Oct 2008 - 01 of YANG, DSDL, architecture, YIN, and standard
> library draft.  If split out, -00 of on-the-wire XML draft.
> 
> Feb 2009 - WGLC for architecture doc
> 
> Mar 2009 - Submit the architecture doc to the IESG for
> publication as an Informational RFC
> 
> Aug 2009 - WGLC for YANG, YIN, XML on-the-wire (if split out),
> YANG standard library, DSDL mapping rules
> 
> Sep 2009 - Submit YANG, YIN, XML on-the-wire (if split out), YANG
> standard library, DSDL mapping rules to the IESG for publication as a
> Proposed Standard
> _______________________________________________
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2008 10:08:49 -0700

> 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).

> removed. Rather, the first work item should be to select a technical

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

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 19:14:10 +0200

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-masked] [mailto:[email-masked]]Namens Eric
> Rescorla
> Verzonden: dinsdag 22 april 2008 18:10
> Aan: [email-masked]; [email-masked]
> Onderwerp: Re: WG Review: NETCONF Data Modeling Language (netmod)
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Apr 2008 10:25:55 -0700

At Tue, 22 Apr 2008 10:08:49 -0700,
> the purpose of that BoF had been fulfilled.

Agreed.

> 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.

> 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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 22 Apr 2008 13:04:42 -0600

Hi -

> From: "Eric Rescorla" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 22, 2008 10:10 AM
> Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)
...
> removed. Rather, the first work item should be to select a technical
...

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

---

From: David Partain <[email-masked]>
Date: Tue, 22 Apr 2008 23:00:53 +0200

Greetings,

> 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.

> direction. 

Not surprisingly, I disagree.

The O&M 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 O&M 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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Apr 2008 14:06:57 -0700

At Tue, 22 Apr 2008 19:14:10 +0200,
> REALLY... ????

Yes, really.

> 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.

> 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.

> we would need long in a newly formed WG to come to the same

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Apr 2008 14:14:01 -0700

At Tue, 22 Apr 2008 23:00:53 +0200,
> I'm not surprised that he objects now.

Of course, since the issues I was concerned about from the very
beginning remain.

> 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

> was a reasonable way forward.  So, we have consensus amongst the various 

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

---

From: David Partain <[email-masked]>
Date: Tue, 22 Apr 2008 23:11:06 +0200

On Tuesday 22 April 2008 23.06.57 Eric Rescorla wrote:
> 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

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 23:10:53 +0200

W.r.t.
> discussion in the BOF and gettting consensus, nor is it a substitute

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

---

From: David Partain <[email-masked]>
Date: Tue, 22 Apr 2008 23:14:17 +0200

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2008 14:14:03 -0700

> 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.

Andy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Apr 2008 14:18:26 -0700

At Tue, 22 Apr 2008 23:10:53 +0200,
> 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

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 23:16:02 +0200

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 

> Verzonden: dinsdag 22 april 2008 23:14
> Aan: David Partain
> CC: [email-masked]; [email-masked]

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 23:23:29 +0200

Well said Andy.

And I support the charter as well!

Bert Wijnen 

> Van: [email-masked] [mailto:[email-masked]]Namens Andy
> Bierman
> Aan: Randy Presuhn
> CC: [email-masked]

---

From: David Partain <[email-masked]>
Date: Tue, 22 Apr 2008 23:32:01 +0200

Hi all,

> for this technical approach.

Absolutely.  Well said.

David

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Apr 2008 14:56:40 -0700

At Tue, 22 Apr 2008 23:16:02 +0200,
> 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

> 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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 22 Apr 2008 19:17:47 -0600

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Apr 2008 20:55:08 -0700

At Tue, 22 Apr 2008 19:17:47 -0600,
Randy Presuhn wrote:
> 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
> 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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Apr 2008 21:03:54 -0700

> additional perspectives from those not already committed to a

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 22 Apr 2008 21:52:18 -0600

Hi -

> From: "Dave Crocker" <[email-masked]>
> To: "Eric Rescorla" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 22, 2008 10:03 PM
...
> 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.

> 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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Apr 2008 02:59:37 -0400

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-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Crocker
> Sent: Wednesday, April 23, 2008 12:04 AM
> To: Eric Rescorla
> Cc: [email-masked]; [email-masked]

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 together at the OPS Open area meeting and at the OPS/IESG
breakout meetings to discuss a way forward, and the various
constituencies reached agreement that YANG provoded a reasonable
human-friendly language, and a translation to either XSD or RNG would
meet the needs for a machine-friendly language suitable for XML-based
tools. Consensus of these constituencies was that RNG + Schematron
(i.e., DSDL) provided better capabilities for validation of the
network management specific requirements than XSD alone or RNG alone.
The consensus of the these constituencies was also that YANG was more
human-friendly then either XSD or RNG or DSDL. 

So constituencies of the "broader community" have been very active in
establishing the proposed direction, in crafting the proposed charter,
and have committed to working on the documents identified in the
proposed charter. 

> developed their own group consensus?

This topic is not new, and constituencies of the "broader community"
have been active in establishing the proposed direction, and the
proposed charter, and have committed to working on the documents
identified in the proposed charter. 

> Rather than "perspectives" where are the technical concerns 

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Apr 2008 09:39:13 +0200

> there weren't hums taken in PHL that that meant no hums would
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

---

From: David Partain <[email-masked]>
Date: Wed, 23 Apr 2008 14:04:21 +0200

Hi,

I should probably just sit down and be quiet, but I have a few comments.

> additional perspectives from those not already committed to a

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.

> (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.

> 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.

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Apr 2008 07:45:02 -0700

At Wed, 23 Apr 2008 09:39:13 +0200,
> 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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Apr 2008 07:44:58 -0700

> 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.

> 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.

Andy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Apr 2008 08:06:58 -0700

Folks,

The exchange over netmod was one of the more pragmatic and encouraging threads 
I've seen in the IETF in a very long time.  I think it crystallized the core 
criteria that ought to drive the decision for chartering a group.

Rather than filter them through my own re-wording, here are the tidbits that I 
think stated things quite nicely:

Bert Wijnen - IETF wrote:
> instead of discussing if there was consensus AT THE BOF (we all know that
> at this point in time we DO have consensus between all the interested
> WORKERS in this space,

Andy Bierman wrote:
> The 15 people on the design team represented a wide cross section of those
> actually interested in this work. I am among the 10 - 15 people who were
> not involved in the design team, but agree with the charter. That seems
> like a lot of consensus for this technical approach.

David Partain wrote:
> The O&M 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
> O&M community and with the APPS area people who were involved that this was
> a reasonable approach forward.
...
>  in it _does_ agree that we have consensus to move forward in this
> direction, that there has been public scrutiny of the proposal, and that
> it's time to move on.

Bert Wijnen - IETF wrote:
 > see the usefulness of that discussion...

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 23 Apr 2008 08:39:56 -0700

> 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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Apr 2008 11:49:06 -0400

> Behalf Of Eric Rescorla

> 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 different goals, like
building SMI atop ASN.1, when the standards are likely to grow in
different directions than what we need for IETF NM data model
standardization purposes.

Unfortunately, you did not attend the many sessions over the past few
years as the NM community did comparisons of the suitability of SMIv2,
SPPI, SMING, XSD, RNG, YANG and others for purposes of configurastion
data modeling. But the community that has attended such discussions of
the suitability of different languages for the task at hand has
reached rough consensus and developed multiple implementations of
running code for this proposed direction forward. 

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Apr 2008 09:52:08 -0700

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

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 23 Apr 2008 17:27:12 -0400

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.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 23 Apr 2008 14:56:40 -0700

>>>>> On Wed, 23 Apr 2008 07:45:02 -0700, Eric Rescorla <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 24 Apr 2008 09:22:22 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'Eric Rescorla'" <[email-masked]>; "'Bert Wijnen - IETF'"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 23, 2008 5:49 PM
Subject: RE: WG Review: NETCONF Data Modeling Language (netmod)

> 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 O&M 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>

---

From: David Partain <[email-masked]>
Date: Thu, 24 Apr 2008 11:15:29 +0200

Hi all,

> 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 O&M 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 O&M 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 O&M 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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 24 Apr 2008 23:06:04 -0400

Hi,

Netconf work has been discussed on multiple different mailing lists.
To help IETF participants to find the various discussions relateds to
Netconf data modeling langauges, here is a historical listing of where
the discussions have taken place (starting in Sep 07; if anybody wants
pointers to the earlier discussions, just ask).

An overview of where discussions are held:
Netconf protocol: [email-masked]
Netconf Going On: [email-masked]
Requirements for Netconf Data Modeling Languages:
http://www.partain.se/pipermail/rcdml/
YANG design details: [email-masked]

Sep07: A NDM BOF was requested at ietf70 to discuss creating a WG for
Netconf data modeling
(http://www.ietf.org/mail-archive/web/ngo/current/msg00260.html). This
thread contains a long discussion about whether a new DML is needed,
whether XSD or RNG meet the requirements, and discusses a two-tiered
approach. 

The IESG and IAB held discussions and the BOF was not approved. I do
not know if these discussions are documented.

To help the Netconf community be aware of Netconf-related work at
IETF70, the following was posted to the NGO mailing list:
http://www.ietf.org/mail-archive/web/ngo/current/msg00397.html

Some discussions were held on the NGO mailing list, whose archive can
be found at
http://www.ietf.org/mail-archive/web/ngo/current/maillist.html.
A discussion thread on why Netconf needs a data modeling langauge can
be found at
http://www.ietf.org/mail-archive/web/ngo/current/msg00408.html

IETF70:

A discussion was held in the APPS open area meeting of IETF70 instead.
The APPS area open meeting discussed why this work was needed. The
minutes unfortunately summarize this extremely lightly, and the
discussion of whether existing languages could be used was summarized
as "whether the use of schema languages was dismissed too easily",
without capturing the lengthy discussion on this point. 

The details of the discussion can be heard at
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf70/ietf70-ch1-
mon-am-apparea.mp3, starting at approximately 53 minutes into the
recording. A consensus call was made to determine whether there was
support for a BOF based on concrete proposals. Strong consensus for a
BOF. Concrete proposals should explain what each does well, and what
common requirements are met by the model. 

Additional discussion occurred during the OPS Open Area meeting, with
some comparion of proposals. MP3 audio is available at
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf70/ietf70-ch5-
mon-eve-opsarea.mp3 (starting at 2:17).

http://www.ietf.org/mail-archive/web/ngo/current/msg00489.html details
the request for a BOF to compare approaches to NETCONF Modeling
(CANMOD).

To help make the BOF more effective, the community decided to gather
requirements from the various data modeling language constituencies,
the results of which could be used to compare the concrete proposals.
A public announcement of an ad-hoc meeting to discuss requirements was
posted to the NGO mailing list
(http://www.ietf.org/mail-archive/web/ngo/current/msg00456.html).

The OPS ADs decided to create a design team to document the
requirements. The RCDML mailing list has been made available so people
can see what was discussed. See
http://www.partain.se/pipermail/rcdml/. The latest rev can be found at
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-presuhn-rcdml-
03.txt

Between IETF70 and IETF71, the IESG and IAB reached an agreement that
no proposals could be discussed at the BOF. I do not know if those
discussions are available anywhere.

IETF71:

The output of the RCDML requirements-gathering effort was published
and presented at the CANMOD BOF at IETF71. Minutes are available at
http://www.ietf.org/proceedings/08mar/minutes/canmod.txt. The
following consensus points were noted:
 - Are the requirements adequately understood?  The sense of the
    room was that the requirements are adequately understood.

  - Is there a need for this work?  The sense of the room was
    that there is a need for this work.

  - Is there sufficient agreement on the requirements
    to permit progress?  This was also the sense of the room.

  - Should an IETF working group be formed?  The sense of the
    room was that a working group to develope a Data Modeling
    Language suitable for NETCONF should be formed.

  - Would additional time spent on requirements gathering
    and analysis be well-spent?  The sense of the room was
    clearly "NO" on this question.

The OPS Open Area meeting discussed Netconf DML proposals. The minutes
are at  http://www.ietf.org/proceedings/08mar/minutes/opsarea.txt. The
MP3 audio is at
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf71/ietf71-ch5-
wed-noon-opsarea.mp3

Consensus was reached that YANG and RelaxNG were liked by the most
non-author readers of the proposals, but people really liked different
aspects of the proposals.

The discussion continued in the IESG Breakout room the following day.
We do not have 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-masked]
[email-masked]
[email-masked]

> Sent: Tuesday, April 22, 2008 5:18 PM
> To: Bert Wijnen - IETF