Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Wed, 2 Apr 2008 16:36:02 +0200

Dear NETCONF WG,

after having sent out the preliminary minutes we need to 
confirm a few results of the NETCONF session. Below is a 
summary. We'll send out separate mails for important topics
for confirmation.

=> Authors of WG items: 
Please prepare a new version of your document.

=> WG members: 
Please review updated documents and trigger a 
discussion promptly.

( *) indicates that a separate confirmation mail will be sent out)

A) Ongoing or planned implementations for the chartered items:

*) (Planned) Implementations of Partial Lock (3 hands):
Martin B, Balazs?, Sharon

*) (Planned) Implementations of NETCONF Monitoring (4 hands):
Martin B, Andy, Sharon, Mark

*) (Planned) Implementations of NETCONF over TLS:
No one in the audience was planning to implement.
After the meeting Mohamad Badra stated that he is 
implementing.

<Note of the chairs>
We need 2 implementations to be able to get it to draft 
standard status. We think that even for a proposed standard, 
it makes no sense if only one single person is planning to 
implement. A standards track document should be implemented 
by many (at least 2, but preferably many more). 

Therefor the chairs have the opinion that it does not 
make sense to standardize the document if there is no 
other interested party to implement. 
So, please respond to the parallel mail if there is anybody 
implementing or planning to implement.
</Note>

TLS draft issues and AIs:
There were a few issues discussed in the session. Since Badra 
was not there we couldn't asnwer all and got some action 
items.
Chairs note: This topic is on hold till we have an answer on
how many implementations are planned for NETCONF over TLS. 

*) (Planned) Implementations of the Notification draft (4 hands):
Martin B, Sharon (2?), Mark

B) Interoperability event:

In the NETCONF session we asked whether anybody is 
interested in an interoperability event for chartered 
documents or on the published RFCs or both. An 
additional goal would be to prepare a test report 
to shift NETCONF RFCs to the draft standard status. 

There was nobody in the WG session interested in an 
interoperability event.

=> If anybody is interested in an interoperability 
    event for chartered documents or on the 
    published RFCs please bring it up on the list.

C) Potential documents for non-chartered topics:

*) Access Control:
Andy Bierman and David Harrington in the session and 
Kaushik Narayan after the session showed interest to 
work on Access Control. 

*) Netconf content:
There was interest to prepare I-D's for NETCONF 
Content for CONFIGURATION (and/or NETCONF related) 
events and also NETCONF Content for SNMP or SYSLOG 
notifications. 

D) Other discussion which needs to be brought to the 
NETCONF list:

=> Wes Hardaker: 
Please post your questions on:
- what happens if you copy candidate to running 
  while a partial lock is held? 
- need a matrix that covers the various operations 
  and their interaction
Please also post any other questions that we may 
have missed above.

E) SOAP implementation presentation 

=> Folks who volunteer to read and comment to 
    improve the quality please send your comments 
    to Dan Romascanu and copy the NETCONF maillist.

Thank you for your support.

Bert & Mehmet

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Apr 2008 16:47:05 +0200 (CEST)

Hi,

>     published RFCs please bring it up on the list.

I don't know why I missed this one...  My company is intersted in such
an event.  We have implementations for both the client and server
side.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Apr 2008 16:47:05 +0200 (CEST)

Hi,

/martin

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 07 Apr 2008 16:33:53 -0700

>>>>> "ME" == Mehmet Ersue <Ersue> writes:

ME> => Wes Hardaker: 
ME> Please post your questions on:
ME> - what happens if you copy candidate to running 
ME> while a partial lock is held? 

Here's a quick summary about partial vs global commands.  Locking is one
type of command that has both a global (in the core netconf model) and
partial (in the newly proposed partial locking draft).

Global commands are those that operate on entire configuration
datastores at once.  EG, <copy-config>, <delete-config>, <lock>, ...  It
affects the whole configuration datastore or it doesn't.  If, when
authorization comes along, a netconf user don't have write access to the
whole configuration store it's currently undefined as to what happens,
though some obvious things are probably apparent (a copy-config by a
user with restricted access shouldn't be allowed to change parts of a
config being copied TO that they're not authorized to change).

ParFrom [email-masked]  Mon Apr  7 16:36:11 2008
From: Wes Hardaker <[email-masked]>
To: "Ersue\, Mehmet \(NSN - DE\/Muenich\)" <[email-masked]>
Organization: Sparta
Date: Mon, 07 Apr 2008 16:33:53 -0700
Cc: [email-masked]
Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 and
	Action Items
Sender: [email-masked]

>>>>> "ME" == Mehmet Ersue <Ersue> writes:

ME> => Wes Hardaker: 
ME> Please post your questions on:
ME> - what happens if you copy candidate to running 
ME> while a partial lock is held? 

Here's a quick summary about partial vs global commands.  Locking is one
type of command that has both a global (in the core netconf model) and
partial (in the newly proposed partial locking draft).

Global commands are those that operate on entire configuration
datastores at once.  EG, <copy-config>, <delete-config>, <lock>, ...  It
affects the whole configuration datastore or it doesn't.  If, when
authorization comes along, a netconf user don't have write access to the
whole configuration store it's currently undefined as to what happens,
though some obvious things are probably apparent (a copy-config by a
user with restricted access shouldn't be allowed to change parts of a
config being copied TO that they're not authorized to change).

Partial ctial commands are those that operate on pieces of a configuration
datastore.  Examples include <edit-config> and <partial-lock> (I don't
remember the exact command name for that, unfortunately...  That may not
be it).  In these types commands the user will or will not have the
ability to execute the command based on what part of a datastore it's
acting upon.  IE, a user will be prohibited from partically-locking a
part of a datastore it doesn't have the authorization to lock.

The trouble comes in when trying to mix these modes.  Consider the case
where two different operators have different access rights to a
particular configuration datastore (if you want an example where this is
going to be required for new work, see
draft-hardaker-dnsops-name-server-management-reqs-02.txt which documents
management requirements for DNS management).  If you have two different
users (say U1 and U2) that are responsible for separate pieces of the
configuration datastore you can run into conflicts between them.  If,
for example, U1 has the ability to edit only the routing information and
U2 only has the ability to edit DNS service configuration then if
they're both trying to configure their parts of the system at the same
time then everything works just fine as long as they don't use any
global commands.

EG, if they both partially lock their portions of "running", edit it,
and then unlock they'll never see problems.

However, if they both partially lock the candidate config, edit it such
that there are outstanding changes to both the routing configuration and
the DNS service configuration then it's possible neither U1 nor U2 will
have access rights to perform the copy-config to actually copy the
changes made from the candidate to the running configuration.  U1 won't
be able to since changes exist in the DNS configuration portion and he
doesn't have write access to that portion of the running config, and
vice-versa for U2 with respect to the routing configuration.

A partial-lock is another form of a partial config and that was my only
point in the meeting.  It doesn't add new problems, it just compounds
the study case.  EG, if U2 partially locks the DNS service configuration
portion of running then it prevents U1 from performing a copy from
candidate to running which blocks U1 from the edit path they wished to
take.  The only choice is for U1 to do edits only on running (or wait
for the partial-lock to be lifted which may be never if mal-intent is
involved).

ME> - need a matrix that covers the various operations and their
ME> interaction

That was just a comment that a "nice to have" piece of documentation
would be a chart that displayed which commands had what affect on which
pieces of the whole system.  As new pieces/operations/commands keep
getting added to the system it gets more and more complex to study from
any perspective, and most importantly, a security perspective.

But to be clear I'm not misunderstood: I think partial-locking is a good
thing, not a bad thing.  I actually think the system would be easier if
it disallowed global commands altogether.  But that's another story for
another day and will only likely caused me to get flamed off the mailing
list ;-/
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

ommands are those that operate on pieces of a configuration
datastore.  Examples include <edit-config> and <partial-lock> (I don't
remember the exact command name for that, unfortunately...  That may not
be it).  In these types commands the user will or will not have the
ability to execute the command based on what part of a datastore it's
acting upon.  IE, a user will be prohibited from partically-locking a
part of a datastore it doesn't have the authorization to lock.

The trouble comes in when trying to mix these modes.  Consider the case
where two different operators have different access rights to a
particular configuration datastore (if you want an example where this is
going to be required for new work, see
draft-hardaker-dnsops-name-server-management-reqs-02.txt which documents
management requirements for DNS management).  If you have two different
users (say U1 and U2) that are responsible for separate pieces of the
configuration datastore you can run into conflicts between them.  If,
for example, U1 has the ability to edit only the routing information and
U2 only has the ability to edit DNS service configuration then if
they're both trying to configure their parts of the system at the same
time then everything works just fine as long as they don't use any
global commands.

EG, if they both partially lock their portions of "running", edit it,
and then unlock they'll never see problems.

However, if they both partially lock the candidate config, edit it such
that there are outstanding changes to both the routing configuration and
the DNS service configuration then it's possible neither U1 nor U2 will
have access rights to perform the copy-config to actually copy the
changes made from the candidate to the running configuration.  U1 won't
be able to since changes exist in the DNS configuration portion and he
doesn't have write access to that portion of the running config, and
vice-versa for U2 with respect to the routing configuration.

A partial-lock is another form of a partial config and that was my only
point in the meeting.  It doesn't add new problems, it just compounds
the study case.  EG, if U2 partially locks the DNS service configuration
portion of running then it prevents U1 from performing a copy from
candidate to running which blocks U1 from the edit path they wished to
take.  The only choice is for U1 to do edits only on running (or wait
for the partial-lock to be lifted which may be never if mal-intent is
involved).

ME> - need a matrix that covers the various operations and their
ME> interaction

That was just a comment that a "nice to have" piece of documentation
would be a chart that displayed which commands had what affect on which
pieces of the whole system.  As new pieces/operations/commands keep
getting added to the system it gets more and more complex to study from
any perspective, and most importantly, a security perspective.

But to be clear I'm not misunderstood: I think partial-locking is a good
thing, not a bad thing.  I actually think the system would be easier if
it disallowed global commands altogether.  But that's another story for
another day and will only likely caused me to get flamed off the mailing
list ;-/
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 9 Apr 2008 12:03:42 -0600

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, April 07, 2008 5:33 PM
> Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items
...
> thing, not a bad thing.

Agree.

>  I actually think the system would be easier if
> it disallowed global commands altogether.
....

Although one can think of global locks as simply being 
pathologically large partial locks.  But I agree that the
system design is probably much simpler if one starts
from the outset assuming the need for partial locks.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 9 Apr 2008 12:03:42 -0600

Hi -

...

Agree.

....

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 10 Apr 2008 06:34:58 -0700

>>>>> "RP" == Randy Presuhn <[email-masked]> writes:

>> it disallowed global commands altogether.
RP> ....

RP> Although one can think of global locks as simply being 
RP> pathologically large partial locks.  But I agree that the
RP> system design is probably much simpler if one starts
RP> from the outset assuming the need for partial locks.

I meant all global commands though.  The problem with global commands
(like copy-config, not just lock) is that they have to be able to
pseudo-operate on sections of the config that aren't supposed to be
edited by a given user.  Fortunately, if a copy-config contains the
exact same config as what's installed you can pseudo-allow it to
complete.  But if it doesn't (say somethings changed somewhere else
since you grabbed your reference copy to edit) then it:

1) the copy-config From [email-masked]  Thu Apr 10 06:36:06 2008
From: Wes Hardaker <[email-masked]>
To: "Randy Presuhn" <[email-masked]>
Organization: Sparta
Date: Thu, 10 Apr 2008 06:34:58 -0700
Cc: [email-masked]
Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71
	andAction Items
Sender: [email-masked]

>>>>> "RP" == Randy Presuhn <[email-masked]> writes:

>> it disallowed global commands altogether.
RP> ....

RP> Although one can think of global locks as simply being 
RP> pathologically large partial locks.  But I agree that the
RP> system design is probably much simpler if one starts
RP> from the outset assuming the need for partial locks.

I meant all global commands though.  The problem with global commands
(like copy-config, not just lock) is that they have to be able to
pseudo-operate on sections of the config that aren't supposed to be
edited by a given user.  Fortunately, if a copy-config contains the
exact same config as what's installed you can pseudo-allow it to
complete.  But if it doesn't (say somethings changed somewhere else
since you grabbed your reference copy to edit) then it:

1) the copy-cwill fail because you don't have authorization.
2) if you do have authorization, you'll just have wiped out someone
   else's changes that occurred since you grabbed your reference copy

Only using edit-config and partial operations is a much safer way to go.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

onfig will fail because you don't have authorization.
2) if you do have authorization, you'll just have wiped out someone
   else's changes that occurred since you grabbed your reference copy

Only using edit-config and partial operations is a much safer way to go.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 10 Apr 2008 11:05:11 -0600

Hi -

> Sent: Thursday, April 10, 2008 7:34 AM
...
> 1) the copy-config will fail because you don't have authorization.
>    else's changes that occurred siFrom [email-masked]  Thu Apr 10 11:04:23 2008
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Date: Thu, 10 Apr 2008 11:05:11 -0600
Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71
	andAction Items
Sender: [email-masked]

Hi -

> Sent: Thursday, April 10, 2008 7:34 AM
...
> 1) the copy-config will fail because you don't have authorization.
>    else's changes that occurnce you grabbed your reference copy
> 
...

We're in agreement.  But I think there's a bit more to the problem.
If you think about the problem space as *network* configuration
management (and not merely device configuration management),
it becomes clear that the "global" commands just get a piece of the
network's configuration.  But we're on the path to re-inventing
ISO 11587:1996, and I don't think we want that particular camel in
this tent.  :-)

Randy

red since you grabbed your reference copy
...

We're in agreement.  But I think there's a bit more to the problem.
If you think about the problem space as *network* configuration
management (and not merely device configuration management),
it becomes clear that the "global" commands just get a piece of the
network's configuration.  But we're on the path to re-inventing
ISO 11587:1996, and I don't think we want that particular camel in
this tent.  :-)

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 11 Apr 2008 06:16:12 -0700

>>>>> "RP" == Randy Presuhn <[email-masked]> writes:

RP> But we're on the path to re-inventing ISO 11587:1996, and I don't
RP> think we want that particular camel in this tent.  :-)

Then we'll be sure to call it a elephant instead so it's not a problem
this time.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 11 Apr 2008 06:16:12 -0700

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Mon, 14 Apr 2008 11:56:19 +0200

Hi All,
 
we sent out a summary of the IETF 71 NETCONF 
session and six requests to confirm the discussion 
in the WG session (results of a WG session need 
to be confirmed on the maillist).
 
Unfortunately there was not much feedback on 
these mails. Below is a summary:
 
- Martin B. is interested in an interoperability eveFrom [email-masked]  Mon Apr 14 02:56:00 2008
Content-class: urn:content-classes:message
Date: Mon, 14 Apr 2008 11:56:19 +0200
From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
To: <[email-masked]>
Subject: [Netconf] Confirmation of Implementation and Drafting plans WAS:
	RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems
Sender: [email-masked]

This is a multi-part message in MIME format.
Hi All,
 
we sent out a summary of the IETF 71 NETCONF 
session and six requests to confirm the discussion 
in the WG session (results of a WG session need 
to be confirmed on the maillist).
 
Unfortunately there was not much feedback on 
these mails. Below is a summary:
 
- Martin B. is interested in an interoperabilint for chartered
documents
 
Confirmed Notification draft Implementations:
- Martin B.
 
Confirmed NETCONF Monitoring Implementations:
- Martin B. 
- Andy B. confirmed his plan to implement with low priority
 
Confirmed Partial Locking Implementations:
- Martin B. 
 
Confirmed NETCONF over TLS Implementations:
- Mohamad Badra I
- Mohamad Badra II (planned as implementation with a different code
base)
 
Draft for Netconf Content:
- ???
 
Draft for Notification Content:
- Sharon (will check with her organization)
 
Draft for Access Control:
- will be deferred a meeting cycle

==> How about others ? 
 
Is anybody else going to implement current 
charter items or to draft the listed topics ?
 
PLEASE CONFIRM your implementation and drafting 
plans on the maillist. Thank you!
 
PS: As you know we need _at least_ two implementations 
for a standard track document. 
 
Cheers,
Mehmet 

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich)
	Sent: Wednesday, April 02, 2008 4:36 PM
	To: [email-masked]
	Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71
and ActionItems

	Dear NETCONF WG, 

	=> Authors of WG items: 

	=> WG members: 

	( *) indicates that a separate confirmation mail will be sent
out) 

	<Note of the chairs> 

	*) (Planned) Implementations of the Notification draft (4
hands): 
	Martin B, Sharon (2?), Mark 

	*) Access Control: 

	*) Netconf content: 
	ety event for chartered
documents
 
Confirmed Notification draft Implementations:
- Martin B.
 
Confirmed NETCONF Monitoring Implementations:
- Martin B. 
- Andy B. confirmed his plan to implement with low priority
 
Confirmed Partial Locking Implementations:
- Martin B. 
 
Confirmed NETCONF over TLS Implementations:
- Mohamad Badra I
- Mohamad Badra II (planned as implementation with a different code
base)
 
Draft for Netconf Content:
- ???
 
Draft for Notification Content:
- Sharon (will check with her organization)
 
Draft for Access Control:
- will be deferred a meeting cycle

==> How about others ? 
 
Is anybody else going to implement current 
charter items or to draft the listed topics ?
 
PLEASE CONFIRM your implementation and drafting 
plans on the maillist. Thank you!
 
PS: As you know we need _at least_ two implementations 
for a standard track document. 
 
Cheers,
Mehmet 

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich)
	Sent: Wednesday, April 02, 2008 4:36 PM
	To: [email-masked]
	Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71
and ActionItems

	Dear NETCONF WG, 

	=> Authors of WG items: 

	=> WG members: 

	( *) indicates that a separate confirmation mail will be sent
out) 

	<Note of the chairs> 

	*) (Planned) Implementations of the Notification draft (4
hands): 
	Martin B, Sharon (2?), Mark 

	*) Access Control: 

	*) Netconf content: 
	There was interest to prepare I-D's for NETCONF 
	Content for CONFIGURATION (and/or NETCONF related)vents and also NETCONF Content for SNMP or SYSLOG 
	notifications. 

	=> Wes Hardaker: 

	Bert & Mehmet

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 14 Apr 2008 08:29:13 -0400

Hi,
 
> for a standard track document. 

Can you identify the RFC that describes the standards process that has
this requirement? I thought we were developing standards according to
the IETF standards process as documented in RFC2026:

"  A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has
received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation."

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 14 Apr 2008 08:29:13 -0400

Hi,

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

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Mon, 14 Apr 2008 14:52:53 +0200

Inline

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]]Namens
> David B Harrington
> Verzonden: maandag 14 april 2008 14:29
> Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; [email-masked]
> Onderwerp: Re: [Netconf] Confirmation of Implementation and Drafting
> plansWAS:RE: Summary of the NETCONF WG Session in IETF 71 and
> ActionItems
> 
> 
> Hi,
>  
> this requirement?

Dave, the below is correct. But we were not asking that the spec would be
implemented by the time we get to PS. We were asking if anyone had plans
to implement NetConf over TLS (anytime as far as I am concerned). And my 
view is that if we have not at least 2 independent impleemntation plans,
that I do not see why we would standardize.

Bert
> I thought we were developing standards according to

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Mon, 14 Apr 2008 14:52:53 +0200

Inline

Bert Wijnen 

Bert

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Mon, 14 Apr 2008 14:57:50 +0200

Summary of the NETCONF WG Session in IETF 71 and Action ItemsLet me (as
co-chair) also chime in here.
You may have found other WGs where WG chairs assume that silence means
consent.
We however would rather see people explicitly express their
interest/plans/volunteership
etc. I personally certainly do not like the idea of "silence means consent",
except in
cases where we as chairs state that that will be our assumption.

Bert Wijnen
  -----Oorspronkelijk bericht-----
  Van: Ersue, Mehmet (NSN - DE/Muenich) [mailto:[email-masked]]
  Verzonden: maandag 14 april 2008 11:56
  Aan: [email-masked]
  CC: Bert Wijnen - IETF
  Onderwerp: Confirmation of Implementation and Drafting plans WAS: RE:
[Netconf] Summary of the NETCONF WG Session in IETF 71 and ActionItems

  Hi All,

  - Martin B. is interested in an interoperability event for chartered
documents

  Confirmed NETCONF over TLS Implementations:
  - Mohamad Badra I
  - Mohamad Badra II (planned as implementation with a different code base)

  ==> How about others ?

  Cheers,
  Mehmet

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich)
    Sent: Wednesday, April 02, 2008 4:36 PM
    To: [email-masked]
    Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71 and
ActionItems

    Dear NETCONF WG,

    => Authors of WG items:

    => WG members:

    <Note of the chairs>

    *) Access Control:

    *) Netconf content:

    => Wes Hardaker:

    Bert & Mehmet

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Mon, 14 Apr 2008 14:57:50 +0200

Bert Wijnen
  -----Oorspronkelijk bericht-----
  Van: Ersue, Mehmet (NSN - DE/Muenich) [mailto:[email-masked]]
  Verzonden: maandag 14 april 2008 11:56
  Aan: [email-masked]
  CC: Bert Wijnen - IETF
  Onderwerp: Confirmation of Implementation and Drafting plans WAS: RE:

  Hi All,

  ==> How about others ?

  Cheers,
  Mehmet

    Dear NETCONF WG,

    => Authors of WG items:

    => WG members:

    <Note of the chairs>

    *) Access Control:

    *) Netconf content:

    => Wes Hardaker:

    Bert & Mehmet

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 Apr 2008 15:13:21 +0200

David,

You are correct - this formal requirement comes later. We need at least
two implementations with different code bases and demonstrate
interoperability to advance a document from Proposed to Draft. However,
I believe that requiring at least a declaration of intent from two
different entities (vendors, open code implementers, etc.) in order to
charter a work as standards track and then ask the IESG to approve a
document as PS is quite in tune with this formal process requirement
that comes later. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David B Harrington
> Sent: Monday, April 14, 2008 3:29 PM
> To: 'Ersue, Mehmet (NSN - DE/Muenich)'; [email-masked]
> Subject: Re: [Netconf] Confirmation of Implementation and 
> Drafting plansWAS:RE: Summary of the NETCONF WG Session in 
> IETF 71 and ActionItems
> 
> Hi,
>  
> > PS: As you know we need _at least_ two implementations for 
> a standard 
> > track document.
> 
> Can you identify the RFC that describes the standards process 
> that has this requirement? I thought we were developing 
> standards according to the IETF standards process as 
> documented in RFC2026:
> 
>    known design choices, is believed to be well-understood, 
> has received

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 Apr 2008 15:13:21 +0200

David,

Dan

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Mon, 14 Apr 2008 15:38:19 +0200

Hi David,

the RFC text you copied states also:
"However, such experience is highly desirable, and will usually 
represent a strong argument in favor of a Proposed Standard 
designation."

I think this is inline with Dan's statement below. If there is 
nobody with interest or plans to implement a standard track 
document the WG item becomes questionable.

OTOH: We are not that bad! As discussed in the session we have 
already a few individuals who implemented or plan to implement. 
Bert and myself, we would like to have a confirmation to close the 
action point.

Cheers, 
Mehmet

> From: ext Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, April 14, 2008 3:13 PM
> To: David B Harrington; Ersue, Mehmet (NSN - DE/Muenich); 
> [email-masked]
> Subject: RE: [Netconf] Confirmation of Implementation and

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Mon, 14 Apr 2008 15:38:19 +0200

Hi David,

Cheers, 
Mehmet

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 14 Apr 2008 11:14:15 -0400

Hi,

I understand the desire. I wanted to clarify that the WG does not
"need" to have commitments for two implementations; the WG chairs (and
presumably the WG) "wants" commitment for two implementations. I think
it is important to keep what is required for proposed standard and
what is desired distinct. That is my point.

As Bert observes in one of his responses, other implementations may
come later. I have a concern about "shutting down" work based on the
fact that people on the list are not currently committing to
implementation plans. Some people cannot speak for their company and
are not personally implementing. 

I know that Huawei engineers are constrained by strong IT security
policies, and are not allowed to implement as part of their daily
work, so they cannot honestly make such commitments to implement. That
does not mean they are not interested in the standards effort, and
they could contribute toward developing a specification that is
"generally stable, has resolved known design choices, is believed to
be well-understood, has received significant community review, and
appears to enjoy enough community interest to be considered valuable."

Are there any rules to these commitments? Nortel has three commitments
to implement. Is that enough, even if no other vendor commits to do
so? Does a commitment include a commitment to "ship it in product" or
just prototypes?

The issue is that the chairs, by **requiring** such commitments,
significantly raise the entry costs for participation in this WG. I am
not sure that is a good thing to do to ensure a process that is fair
and open to all, which follows IETF-established guidelines for
process, and to ensure vendor-neutral standards; I think this approach
favors certain companies.

I do not object to chairs trying to determine consensus for each
proposal; that is their job. I do not object to chairs constraining
the scope to try to ensure we finish the work and don't try to boil
the ocean. But when the chairs say that two commitments are **needed**
for standards-track proposals, I believe that is not consistent with
IETF policy.

dbh

> From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:[email-masked]]

> Sent: Monday, April 14, 2008 9:38 AM
> To: David B Harrington
> Cc: ext Romascanu, Dan (Dan); [email-masked]; ext Bert Wijnen -
IETF
> Drafting plans WAS:RE: Summary of the NETCONF WG Session in 
> IETF 71 and ActionItems
> 
> 
> Hi David,
>

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 14 Apr 2008 11:14:15 -0400

Hi,

dbh

IETF

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Mon, 14 Apr 2008 18:21:55 +0200

Dave,

we (WG co-chairs) are not trying to raise the (formal) bar at all.
But we want to make sure that whatever work the WG is doing makes
sense. As such, we asked for people to let us know about "implementation
plans" for each of the work items (documents). Pls note the word PLAN.
That is nto a commitment. But we also assume it is not a lightly made
statement and then forgotten about. We do understand that an "implementation
plan" can get trashed/canceled (for all sorts of reasons). And if such
happens,
then too bad.

W.r.t. people not wanting to state any plans in public, we have offered that
such people can send the info to the WG chairs and we commit (note the word
COMMIT) that we will NOT disclose that information and count it as a
"plan to implement by annonymous A" (if we have many, we can have B, C, D
etc.
The more we have, the more it seems that the work we are doing makes sense.

We have CERTAINLY not asked to make commitments to have implementations
complete by the time that we want to publish a document as RFC (at PS).
As you state, that would be outside of the normal requirements (RTG area
does have such a requirment thoug, so if needed we could see if we would
want to require that too; but I do not see a need for that).

Hope this helps/explains.

Bert Wijnen

> Van: David B Harrington [mailto:[email-masked]]
> Verzonden: maandag 1From [email-masked]  Mon Apr 14 09:21:31 2008
From: "Bert Wijnen - IETF" <[email-masked]>
To: "David B Harrington" <[email-masked]>,
	"'Ersue, Mehmet \(NSN - DE/Muenich\)'" <[email-masked]>
Date: Mon, 14 Apr 2008 18:21:55 +0200
Importance: Normal
Cc: [email-masked]
Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans
	WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems
Sender: [email-masked]

Dave,

we (WG co-chairs) are not trying to raise the (formal) bar at all.
But we want to make sure that whatever work the WG is doing makes
sense. As such, we asked for people to let us know about "implementation
plans" for each of the work items (documents). Pls note the word PLAN.
That is nto a commitment. But we also assume it is not a lightly made
statement and then forgotten about. We do understand that an "implementation
plan" can get trashed/canceled (for all sorts of reasons). And if such
happens,
then too bad.

W.r.t. people not wanting to state any plans in public, we have offered that
such people can send the info to the WG chairs and we commit (note the word
COMMIT) that we will NOT disclose that information and count it as a
"plan to implement by annonymous A" (if we have many, we can have B, C, D
etc.
The more we have, the more it seems that the work we are doing makes sense.

We have CERTAINLY not asked to make commitments to have implementations
complete by the time that we want to publish a document as RFC (at PS).
As you state, that would be outside of the normal requirements (RTG area
does have such a requirment thoug, so if needed we could see if we would
want to require that too; but I do not see a need for that).

Hope this helps/explains.

Bert Wijnen

> Van: David B Harrington [mailto:[email-masked]]
> Verzonden: maa4 april 2008 17:14
> Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'
> CC: 'ext Romascanu, Dan (Dan)'; [email-masked]; 'ext Bert Wijnen -
> IETF'
> Onderwerp: RE: [Netconf] Confirmation of Implementation and Drafting
> plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and
> ActionItems
>
>
> Hi,
>

ndag 14 april 2008 17:14
> Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'
> CC: 'ext Romascanu, Dan (Dan)'; [email-masked]; 'ext Bert Wijnen -
> IETF'
> Onderwerp: RE: [Netconf] Confirmation of Implementation and Drafting
> plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and
> ActionItems
>
>
> Hi,
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Apr 2008 10:03:20 -0700

Hi,

Isn't this type of discussion more appropriate before the charter is approved?
IMO, you both have valid arguments.

The most relevant question is whether or not there are enough skilled
people willing to write and review the document, and stay involved
until the 'RFC Announcement' is sent.

Since vendors with no plans to implement are also likely to ignore
the document work, it seems relevant to ask about implementation plans.

When a WG is developing 4 very different work items at once,
you cannot expect that all the WG participants care about all the documents,
or that people should be expected to work on documents they don't care about.

Andy

>> Verzonden: maandag 14 april 2008 17:14

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Apr 2008 10:03:20 -0700

Hi,

Andy