Subject: design team

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 21 Dec 2007 19:13:58 +0100

(resending with correct netconf address and full team membership)

Following the discussions in Vancouver we are creating a design team to work on Requirements for a Configuration Data Modeling Language (RCDML) with participation from OPS and APPS. 

The principal goal of the design team activity is to increase the chances for a successful BOF in Philadelphia which should decide on what needs to be done to standardize data models for configuration in the IETF with focus on the immediate requirements for the NETCONF protocol. We recommend that in order to expedite the process the team will look at the existing requirements for data modeling languages coming from the various teams working on new solutions or reusing existing data modeling languages and tools, identify the common set of requirements and the principal specific requirements that led to each one of the solutions. The focus of the requirements should be on the immediate needs of the OPS area and NETCONF protocol, and should use precedent work done in the area as RFC 3535, but take into consideration the need for extensibility and the opportunity of providing one data modeling language solution for different other IETF problems in APPS and other area like application servers, so that any solution that is engaged does not preclude the extensibility and broader applicability. 

Team leader is Randy Presuhn whom we thank for accepting this task and we welcome back as an active participant in the IETF. We trust that his experience and expertise will be of great help. Members in the team will be Martin Björklund, Sharon Chisholm, Alex Clemm, Rohan Mahy, Chris Newman,  and David Partain

As time frame we suggest that the team targets February 15, 2008 as a date for the principal deliverable which should be an Internet-Draft with a taxonomy of RDCML to be used as entry and reference at a CDML BOF at IETF 71 in Philadelphia. 

We wish success to the team and Happy Holidays for all. 

Ron and Dan

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Dec 2007 10:55:58 -0800

Romascanu, Dan (Dan) wrote:
> Following the discussions in Vancouver we are creating a design team to work on Requirements for
> a Configuration Data Modeling Language (RCDML) with participation from OPS and APPS.
> 
> The principal goal of the design team activity is to increase the chances for a successful BOF
> in Philadelphia which should decide on what needs to be done to standardize data models for
> configuration in the IETF with focus on the immediate requirements for the NETCONF protocol. We
> recommend that in order to expedite the process the team will look at the existing requirements
> for data modeling languages coming from the various teams working on new solutions or reusing
> existing data modeling languages and tools, identify the common set of requirements and the
> principal specific requirements that led to each one of the solutions. The focus of the
> requirements should be on the immediate needs of the OPS area and NETCONF protocol, and should
> use precedent work done in the area as RFC 3535, but take into consideration the need for
> extensibility and the opportunity of providing one data modeling language solution for different
> other IETF problems in APPS and other area like application servers, so that any solution that
> is engaged does not preclude the extensibility and broader applicability.
> 

I would like to object to this charter text.
The name of the presumed BoF (CDML) means Configuration DML, not NETCONF DML.
This implies that the IESG thinks that all configuration is the same,
and any sort of application with configurable parameters of any sort
could use the same data modeling language, regardless of the configuration
protocol being used (if any).

This last phrase is rather vague and open-ended:
    ...opportunity of providing one data modeling language solution for different
    other IETF problems in APPS and other area like application servers, so that
    any solution that is engaged does not preclude the extensibility and broader
    applicability

This sure looks like a "boil the ocean" kind of charter.
Does this include my Apache configuration? bind config? Windows hosts?  Printers?
Is '/sbin/ifconfig' an application included in the charter?

I was at the IAB NM workshop that led to RFC 3535.
The operators made it clear at that meeting they did not
mix router/switch configuration with 'desktop support',
and did not ask for anything of the sort.

> Team leader is Randy Presuhn whom we thank for accepting this task and we welcome back as an
> active participant in the IETF. We trust that his experience and expertise will be of great
> help. Members in the team will be Martin Björklund, Sharon Chisholm, Alex Clemm, Rohan Mahy,
> Chris Newman,  and David Partain
> 
> As time frame we suggest that the team targets February 15, 2008 as a date for the principal
> deliverable which should be an Internet-Draft with a taxonomy of RDCML to be used as entry and
> reference at a CDML BOF at IETF 71 in Philadelphia.
> 

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Dec 2007 14:24:38 -0500

By the way, while I don't expect NETCONF to use the forces XML modeling
(the forces representation is very focussed on the internals, not the
CLI view,) I would be very unhappy if someone were to claim that ForCES
had to start over (we are very close to completing our two primary
drafts and sending them to the IESG) because we "should" use some other
model.

Yours,
Joel M. Halpern

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sat, 22 Dec 2007 00:04:04 +0100

Andy,

I would not spend to much time with exact wordsmithing, because this is not really a 'charter'.  A design team does not need an IESG approved charter. This wording rather reflects the discussions that we as ADs had in Vancouver and what I believe the participants in these discussions agreed would be a good way to help a BOF in Philadelphia have more chances to be successful by identifying what are the agreed requirements and what are the requirements that are different. If you want to discuss the words however, the last phrase that you quote and consider 'open-ended' starts with a clear statement that 'the focus of the requirements should be on the immediate needs of the OPS area and NETCONF protocol'. 

Dan

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Friday, December 21, 2007 8:56 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Randy Presuhn; [email-masked]; 
> [email-masked]; Rohan Mahy; Chris Newman; David Partain; Ron 
> Bonica; Lisa Dusseault; Sharon Chisholm
> Subject: Re: design team
> 
> > Following the discussions in Vancouver we are creating a 
> design team 
> > to work on Requirements for a Configuration Data Modeling 
> Language (RCDML) with participation from OPS and APPS.
> > 
> > The principal goal of the design team activity is to increase the 
> > chances for a successful BOF in Philadelphia which should decide on 
> > what needs to be done to standardize data models for 
> configuration in 
> > the IETF with focus on the immediate requirements for the NETCONF 
> > protocol. We recommend that in order to expedite the 
> process the team 
> > will look at the existing requirements for data modeling languages 
> > coming from the various teams working on new solutions or reusing 
> > existing data modeling languages and tools, identify the 
> common set of 
> > requirements and the principal specific requirements that 
> led to each 
> > one of the solutions. The focus of the requirements should 
> be on the 
> > immediate needs of the OPS area and NETCONF protocol, and 
> should use 
> > precedent work done in the area as RFC 3535, but take into 
> consideration the need for extensibility and the opportunity 
> of providing one data modeling language solution for 
> different other IETF problems in APPS and other area like 
> application servers, so that any solution that is engaged 
> does not preclude the extensibility and broader applicability.
> > 
> 
> 
> This implies that the IESG thinks that all configuration is 
> the same, and any sort of application with configurable 
> parameters of any sort could use the same data modeling 
> language, regardless of the configuration protocol being used 
> (if any).
> 
> The operators made it clear at that meeting they did not mix 
> router/switch configuration with 'desktop support', and did 
> not ask for anything of the sort.
> 
> 
> > Team leader is Randy Presuhn whom we thank for accepting 
> this task and 
> > we welcome back as an active participant in the IETF. We trust that 
> > his experience and expertise will be of great help. Members in the 
> > team will be Martin Björklund, Sharon Chisholm, Alex Clemm, Rohan 
> > Mahy, Chris Newman,  and David Partain
> > 
> > As time frame we suggest that the team targets February 15, 
> 2008 as a 
> > date for the principal deliverable which should be an 
> Internet-Draft 
> > with a taxonomy of RDCML to be used as entry and reference 
> at a CDML BOF at IETF 71 in Philadelphia.
> >

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Sat, 22 Dec 2007 10:17:11 +0100

In Vancouver, I objected quite a bit to doing a "requirements phase".
I am OK with doing a Design Team approach to that. With a clear deadline
of Feb 15 that would be OK and limit the open-ended-ness. I must say
that the charter text does not state it as a "clear deadline", but rather
as a "target". I hope that the intention is that it is a SERIOUS DEADLINE.

The text of the charter also speaks about "focus on NETCONF requirements"
as per thsi text:

   The focus of the requirements should be on the immediate needs of
   the OPS area and NETCONF protocol, and should use precedent work
   done in the area as RFC 3535, but take into consideration the need
   for extensibility and the opportunity of providing one data modeling
   language solution for different other IETF problems in APPS and
   other area like application servers, so that any solution that is
   engaged does not preclude the extensibility and broader applicability.

And as you can see, it also mentions RFC3535.
But I sort have to agree with Andy that already do we see text in here
that asks for "externsibility and the opportunity ...."
That is where I worry. Now... given the limited time the DT has,
they can't really boil the ocean. And if they do not FOCUS on NETCONF
requirements, then they will miss their target of 15 feb or they
will fail. I indeed hope thtat the DT will STAY FOCUSED and in addition
I hope that when the DT finishes, that we do not go through endless
discussions (as has been done for so many other "requirements phases"
in the IETF).

With that, I would Go DT Go! Show us you can do it!

Bert Wijnen

> -----Oorspronkelijk bericht-----
> Van: [email-masked]
> [mailto:[email-masked]]Namens Romascanu, Dan (Dan)
> Verzonden: zaterdag 22 december 2007 0:04
> Aan: Andy Bierman
> CC: [email-masked]; Randy Presuhn; [email-masked]; [email-masked];
> Rohan Mahy; Chris Newman; David Partain; Ron Bonica; Lisa Dusseault;
> Sharon Chisholm
> Onderwerp: RE: design team
>
>
> Andy,
>
> I would not spend to much time with exact wordsmithing, because
> this is not really a 'charter'.  A design team does not need an
> IESG approved charter. This wording rather reflects the
> discussions that we as ADs had in Vancouver and what I believe
> the participants in these discussions agreed would be a good way
> to help a BOF in Philadelphia have more chances to be successful
> by identifying what are the agreed requirements and what are the
> requirements that are different. If you want to discuss the words
> however, the last phrase that you quote and consider 'open-ended'
> starts with a clear statement that 'the focus of the requirements
> should be on the immediate needs of the OPS area and NETCONF protocol'.
>
> Dan
>
>
>
>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sat, 22 Dec 2007 11:30:47 +0100

Well, again, it's not a charter, but rather a summary of what we discussed in Vancouver with the different participants. A design team does not need one. And it's up to the design team to focus the work. The deadline should be seriously taken into consideration. If there is no draft to use as a reference for requirements in Philadelphia a BOF the chances for success are much lessened IMO. The submission deadline for 00 drafts is February 18. 

... And yes, Go DT GO!

... And of course, Happy Holidays!

Dan

> From: Bert Wijnen - IETF [mailto:[email-masked]] 
> Sent: Saturday, December 22, 2007 11:17 AM
> To: Romascanu, Dan (Dan); Andy Bierman
> Subject: RE: design team
> I am OK with doing a Design Team approach to that. With a 
> clear deadline of Feb 15 that would be OK and limit the 
> open-ended-ness. I must say that the charter text does not 
> state it as a "clear deadline", but rather as a "target". I 
> hope that the intention is that it is a SERIOUS DEADLINE.
> 
> But I sort have to agree with Andy that already do we see 
> text in here that asks for "externsibility and the opportunity ...."
> That is where I worry. Now... given the limited time the DT 
> has, they can't really boil the ocean. And if they do not 
> FOCUS on NETCONF requirements, then they will miss their 
> target of 15 feb or they will fail. I indeed hope thtat the 
> DT will STAY FOCUSED and in addition I hope that when the DT 
> finishes, that we do not go through endless discussions (as 
> has been done for so many other "requirements phases"
> in the IETF).
> 
> > CC: [email-masked]; Randy Presuhn; [email-masked]; 
> > [email-masked]; Rohan Mahy; Chris Newman; David Partain; 
> Ron Bonica; 
> > Lisa Dusseault; Sharon Chisholm
> > I would not spend to much time with exact wordsmithing, 
> because this 
> > is not really a 'charter'.  A design team does not need an IESG 
> > approved charter. This wording rather reflects the 
> discussions that we 
> > as ADs had in Vancouver and what I believe the participants 
> in these 
> > discussions agreed would be a good way to help a BOF in 
> Philadelphia 
> > have more chances to be successful by identifying what are 
> the agreed 
> > requirements and what are the requirements that are 
> different. If you 
> > want to discuss the words however, the last phrase that you 
> quote and 
> > consider 'open-ended'
> > > [email-masked]; Rohan Mahy; Chris Newman; David Partain; 
> Ron Bonica; 
> > > Lisa Dusseault; Sharon Chisholm
> > > Subject: Re: design team
> > >
> > > > chances for a successful BOF in Philadelphia which 
> should decide 
> > > > on what needs to be done to standardize data models for
> > > configuration in
> > > consideration the need for extensibility and the opportunity of 
> > > providing one data modeling language solution for different other 
> > > IETF problems in APPS and other area like application servers, so 
> > > that any solution that is engaged does not preclude the 
> > > extensibility and broader applicability.
> > > >
> > >
> > >
> > > This implies that the IESG thinks that all configuration is the 
> > > same, and any sort of application with configurable parameters of 
> > > any sort could use the same data modeling language, regardless of 
> > > the configuration protocol being used (if any).
> > >
> > >     ...opportunity of providing one data modeling 
> language solution 
> > > for different
> > >     any solution that is engaged does not preclude the 
> extensibility 
> > > and broader
> > >     applicability
> > >
> > > router/switch configuration with 'desktop support', and 
> did not ask 
> > > for anything of the sort.
> > >
> > >
> > > > we welcome back as an active participant in the IETF. We trust 
> > > > that his experience and expertise will be of great 
> help. Members 
> > > > in the team will be Martin Björklund, Sharon Chisholm, 
> Alex Clemm, 
> > > > Rohan Mahy, Chris Newman,  and David Partain
> > > >
> > to unsubscribe send a message to 
> [email-masked] with the 
> > word 'unsubscribe' in a single line as the message text body.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 22 Dec 2007 12:35:10 +0100

On Sat, Dec 22, 2007 at 11:30:47AM +0100, Romascanu, Dan (Dan) wrote:

> If there is no draft to use as a reference for requirements in
> Philadelphia a BOF the chances for success are much lessened
> IMO. The submission deadline for 00 drafts is February 18.

I hope the BoF at the IETF 71 will focus on discussing solutions
addressing the requirements.  Your messages worry me because they can
be read like there will be a requirements discussion at IETF 71, which
means another 3-4 months of lost time. In other words, we not only
need a deadline for the design team output, we also need a clear
deadline for the solutions input so that at the IETF 71 a decision can
be taken.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Sat, 22 Dec 2007 12:36:54 +0100

Very well stated!

Bert Wijnen 

> Van: Juergen Schoenwaelder [mailto:[email-masked]]
> Verzonden: zaterdag 22 december 2007 12:35
> Aan: Romascanu, Dan (Dan)
> CC: Bert Wijnen - IETF; Andy Bierman; [email-masked]; Randy
> Presuhn; [email-masked]; [email-masked]; Rohan Mahy; Chris Newman; David
> Partain; Ron Bonica; Lisa Dusseault; Sharon Chisholm
> Onderwerp: Re: design team
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sat, 22 Dec 2007 17:33:08 +0100

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Saturday, December 22, 2007 1:35 PM
> To: Romascanu, Dan (Dan)
> Cc: Bert Wijnen - IETF; Andy Bierman; [email-masked]; 
> Randy Presuhn; [email-masked]; [email-masked]; Rohan Mahy; 
> Chris Newman; David Partain; Ron Bonica; Lisa Dusseault; 
> Sharon Chisholm
> Subject: Re: design team
> 
> > Philadelphia a BOF the chances for success are much 
> lessened IMO. The 
> > submission deadline for 00 drafts is February 18.
> 
> I hope the BoF at the IETF 71 will focus on discussing 
> solutions addressing the requirements.  Your messages worry 
> me because they can be read like there will be a requirements 
> discussion at IETF 71, which means another 3-4 months of lost 
> time. In other words, we not only need a deadline for the 
> design team output, we also need a clear deadline for the 
> solutions input so that at the IETF 71 a decision can be taken.
> 
> /js
> 

The design team role is exactly to make much of the work about
requirements in advance, before Philadelphia, so that at Philadelphia we
do not start from zero and argue again about requirements. So let us
give it a chance. 

Nobody prevents people who work on solutions to work in parallel to
improve and bring their solutions in best shape for Philadelphia as
(Internet-Draft, tools, software).

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 22 Dec 2007 17:41:56 +0100

> do not start from zero and argue again about requirements. So let us

Sure.

> (Internet-Draft, tools, software).

All fine. But I would really dislike that in Philadelphia we say
"nice, now we have some requirements, lets until the next IETF get
proposals on the table and then we discuss proposals". I like the
proposals be discussed in Philadelphia.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 22 Dec 2007 09:08:16 -0800

> do not start from zero and argue again about requirements. So let us

But the design team has been formed by the IESG, and given a set
of criteria by the IESG, for creating the measuring stick by which
the candidate proposals will be judged.

If there are specific applications server requirements that the
Configuration Data Modeling WG needs to address, then they need
to be identified and discussed.  (We will let the design team
have a chance to write specific requirements.)

If there are no specific application server requirements, then
the discussion of solution proposals cannot be very objective.
How can somebody prove that a solution will or will not meet
some unspecified extensibility needs in the future?

I am objecting to the very notion that the NETCONF WG should
compromise the DML needed ASAP for standard NETCONF data models,
for some unspecified 'maybe others will find a use for this someday'
kind of requirements.

If specific WGs (from any area) want a DML very similar in nature
to what the NETCONF WG is pursuing, and domain experts are willing
to help throughout the entire process, then I totally support a combined
solution, instead of N solutions.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 22 Dec 2007 10:46:43 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
...
> Sent: Saturday, December 22, 2007 9:08 AM
> Subject: Re: design team
...
> the candidate proposals will be judged.

That *still* gives no special status to the work.  A design team is
merely that, no matter how it came into being.  If someone starts
treating the design team's output as somehow privileged, that
behaviour is not justified by IETF process.  As anyone who's been
around for a while surely knows, the output of a design team
isn't binding on anyone.

> have a chance to write specific requirements.)

I certainly hope no one reads this as meaning that anyone should
*wait* for the design team.  Additional work identifying requirements
and refining solutions should continue apace, in my opinion.  The
design teams' work should be helpful to the BOF, but is no replacement
for other folks' homework.

> some unspecified extensibility needs in the future?

The logical conclusion of such a line of argument is that the
IETF should do nothing because we cannot prove that all our
solutions will be eternally useful.  However, I do agree that
it would be most helpful for *everyone* who has specific
requirements to state what they are.

> for some unspecified 'maybe others will find a use for this someday'

No one is proposing that we do this.

> solution, instead of N solutions.

While this would be nice, there are good reasons to be skeptical about
the feasability of such a thing.  The design team doesn't plan to even
try to do this, although the requirements from other application spaces
that do configuration will be worth perusing, to identify things applicable
in the netconf domain that may have gone unmentioned.

> > (Internet-Draft, tools, software).

Absolutely.  And I strongly encourage folks to speak up about their
requirements and use cases.

> Andy

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sat, 22 Dec 2007 21:55:11 +0100

Exactly. 
 
Dan

________________________________

	From: Lisa Dusseault [mailto:[email-masked]] 
	Sent: Saturday, December 22, 2007 8:29 PM
	To: Andy Bierman
	Cc: Romascanu, Dan (Dan); [email-masked];
Bert Wijnen - IETF; [email-masked]; Randy Presuhn; [email-masked];
[email-masked]; Rohan Mahy; Chris Newman; David Partain; Ron Bonica;
Sharon Chisholm
	Subject: Re: design team

	On Dec 22, 2007, at 9:08 AM, Andy Bierman wrote:

		But the design team has been formed by the IESG, and
given a set

		of criteria by the IESG, for creating the measuring
stick by which

	No, the design team was formed by Dan and Ron, or rather with
the help of Dan and Ron.  I agree there needs to be space for other
designs, other measuring sticks.

	Lisa