Subject: [Netconf] Request for charter change

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 11 Dec 2008 17:29:09 +0100

Dear ADs (and WG),

based on the consensus after IETF 73 we prepared an update 
for the NETCONF WG charter. 

Dan, Ron: Could you please approve that the extended charter 
text be posted as our current WG charter page and forward it to 
iesg-secretary if approve <<081211_NETCONF WG Charter text.txt>> d 
<<Diff WGCharter-20080821-WGCharter-20081211.htm>> ? 
  
Thank you.

Bert and Mehmet

Attached is the new charter and a rfcdiff of old and new charter.
And here is the main body of the charter text:

Configuration of networks of devices has become a critical requirement
for operators in today's highly interoperable networks. Operators from
large to small have developed their own mechanisms or used vendor
specific mechanisms to transFrom [email-masked]  Thu Dec 11 08:29:28 2008
Content-class: urn:content-classes:message
Date: Thu, 11 Dec 2008 17:29:09 +0100
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Romascanu, Dan (Dan)" <[email-masked]>, <[email-masked]>,
	<[email-masked]>
Subject: [Netconf] Request for charter change
Sender: [email-masked]

This is a multi-part message in MIME format.

Dear ADs (and WG),

based on the consensus after IETF 73 we prepared an update 
for the NETCONF WG charter. 

Dan, Ron: Could you please approve that the extended charter 
text be posted as our current WG charter page and forward it to 
iesg-secretary if approve <<081211_NETCONF WG Charter text.txt>> d 
<<Diff WGCharter-20080821-WGCharter-20081211.htm>> ? 
  
Thank you.

Bert and Mehmet

Attached is the new charter and a rfcdiff of old and new charter.
And here is the main body of the charter text:

Configuration of networks of devices has become a critical requirement
for operators in today's highly interoperable networks. Operators from
large to small have developed their own mechanisms or used vendor
specific mechanisms tofer configuration data to and from a
device, and for examining device state information which may impact
the configuration. Each of these mechanisms may be different in
various aspects, such as session establishment, user authentication,
configuration data exchange, and error responses.

The NETCONF Working Group is chartered to produce a protocol suitable
for network configuration, with the following characteristics:

- Provides retrieval mechanisms which can differentiate between
  configuration data and non-configuration data
- Is extensible enough so that vendors will provide access to all
  configuration data on the device using a single protocol
- Has a programmatic interface (avoids screen scraping and
  formatting-related changes between releases)
- Uses a textual data representation, that can be easily manipulated
  using non-specialized text manipulation tools.
- Supports integration with existing user authentication methods
- Supports integration with existing configuration database systems
- Supports network wide configuration transactions (with features such
  as locking and rollback capability)
- Is as transport-independent as possible
- Provides support for asynchronous notifications.

The NETCONF protocol is using XML for data encoding purposes, because
XML is a widely deployed standard which is supported by a large number
of applications.

The NETCONF protocol should be independent of the data definition
language and data models used to describe configuration and state
data.

However, the authorization model used in the protocol is dependent on
the data model. Although these issues must be fully addressed to
develop standard data models, only a small part of this work will be
initially addressed. This group will specify requirements for standard
data models in order to fully support the NETCONF protocol, such as:

- identification of principals, such as user names or distinguished
names
- mechanism to distinguish configuration from non-configuration data
- XML namespace conventions
- XML usage guidelines

The initial work started in 2003 and has already been completed and was
restricted to following items:

  a) NETCONF Protocol Specification, which defines the operational
model,
     protocol operations, transaction model, data model requirements,
     security requirements, and transport layer requirements.
  b) NETCONF over SSH Specification: Implementation Mandatory,
  c) NETCONF over BEEP Specification: Implementation Optional,
  d) NETCONF over SOAP Specification: Implementation Optional.

  These documents define how the NETCONF protocol is used with each
  transport protocol selected by the working group, and how it meets
  the security and transport layer requirements of the NETCONF Protocol
  Specification.

  e) NETCONF Notification Specification, which defines mechanisms that
     provide an asynchronous message notification delivery service for
     the NETCONF protocol.  NETCONF Notification is an optional
     capability built on top of the base NETCONF definition and
     provides the capabilities and operations necessary to support
     this service.

  The NETCONF notification specification has been finished now as well.

In the current phase of the incremental development of NETCONF the
workgroup will focus on following items:

1. Fine-grain locking: The base NETCONF protocol only provides a lock
   for the entire configuration datastore, which is not deemed to meet
   important operational and security requirements. The NETCONF working
   group will produce a standards-track RFC specifying a mechanism for
   fine-grain locking of the NETCONF configuration datastore.

2. NETCONF monitoring: It is considered best practice for IETF working
   groups to include management of their protocols within the scope of
   the solution they are providing. The NETCONF working group will
   produce a standards-track RFC with mechanisms allowing NETCONF
   itself to be used to monitor some aspects of NETCONF operation.

3. Schema advertisement: Currently the NETCONF protocol is able to
   advertise wh transfer configuration data to and from a
device, and for examining device state information which may impact
the configuration. Each of these mechanisms may be different in
various aspects, such as session establishment, user authentication,
configuration data exchange, and error responses.

The NETCONF Working Group is chartered to produce a protocol suitable
for network configuration, with the following characteristics:

- Provides retrieval mechanisms which can differentiate between
  configuration data and non-configuration data
- Is extensible enough so that vendors will provide access to all
  configuration data on the device using a single protocol
- Has a programmatic interface (avoids screen scraping and
  formatting-related changes between releases)
- Uses a textual data representation, that can be easily manipulated
  using non-specialized text manipulation tools.
- Supports integration with existing user authentication methods
- Supports integration with existing configuration database systems
- Supports network wide configuration transactions (with features such
  as locking and rollback capability)
- Is as transport-independent as possible
- Provides support for asynchronous notifications.

The NETCONF protocol is using XML for data encoding purposes, because
XML is a widely deployed standard which is supported by a large number
of applications.

The NETCONF protocol should be independent of the data definition
language and data models used to describe configuration and state
data.

However, the authorization model used in the protocol is dependent on
the data model. Although these issues must be fully addressed to
develop standard data models, only a small part of this work will be
initially addressed. This group will specify requirements for standard
data models in order to fully support the NETCONF protocol, such as:

- identification of principals, such as user names or distinguished
names
- mechanism to distinguish configuration from non-configuration data
- XML namespace conventions
- XML usage guidelines

The initial work started in 2003 and has already been completed and was
restricted to following items:

  a) NETCONF Protocol Specification, which defines the operational
model,
     protocol operations, transaction model, data model requirements,
     security requirements, and transport layer requirements.
  b) NETCONF over SSH Specification: Implementation Mandatory,
  c) NETCONF over BEEP Specification: Implementation Optional,
  d) NETCONF over SOAP Specification: Implementation Optional.

  These documents define how the NETCONF protocol is used with each
  transport protocol selected by the working group, and how it meets
  the security and transport layer requirements of the NETCONF Protocol
  Specification.

  e) NETCONF Notification Specification, which defines mechanisms that
     provide an asynchronous message notification delivery service for
     the NETCONF protocol.  NETCONF Notification is an optional
     capability built on top of the base NETCONF definition and
     provides the capabilities and operations necessary to support
     this service.

  The NETCONF notification specification has been finished now as well.

In the current phase of the incremental development of NETCONF the
workgroup will focus on following items:

1. Fine-grain locking: The base NETCONF protocol only provides a lock
   for the entire configuration datastore, which is not deemed to meet
   important operational and security requirements. The NETCONF working
   group will produce a standards-track RFC specifying a mechanism for
   fine-grain locking of the NETCONF configuration datastore.

2. NETCONF monitoring: It is considered best practice for IETF working
   groups to include management of their protocols within the scope of
   the solution they are providing. The NETCONF working group will
   produce a standards-track RFC with mechanisms allowing NETCONF
   itself to be used to monitor some aspects of NETCONF operation.

3. Schema advertisement: Currently the NETCONF protocol is able to
   advertich protocol features are supported on a particular
   netconf-capable device. However, there is currently no way to
discover
   which XML Schema are supported on the device. The NETCONF working
   group will produce a standards-track RFC with mechanisms making this
   discovery possible (this item may be merged with "NETCONF monitoring"
   into a single document).

   Note: The schema-advertisement material has been merged into the
   NETCONF monitoring document based on WG consensus.

4. NETCONF over TLS: Based on implementation experience there is a
   need for a standards track document to define NETCONF over TLS as an
   optional transport for the NETCONF protocol.

5. NETCONF default handling: NETCONF today does not define whether
   default values should be returned by the server in replies
   to requests for reading configuration and state data. Different
   clients have different needs to receive or not to receive
   default data. The NETCONF working group will produce a
   standards-track RFC defining a mechanism that allows
   NETCONF clients to control whether default data is returned
   by the netconf server.

6. NETCONF implementations have shown that the specification in RFC4741
   is not 100% clear and has lead to different interpretations and
implementations. 
   Also some errors have been uncovered. So the WG will do an rfc4741bis
with
   following constraints:

     - bug fixes are to be done
     - clarifications can be done
     - no extensions (i.e. we are not doing a NETCONF V2)
     - The work can be started based on the discussion in IETF #73 (see
        http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf).

   Note: A technical errata has been posted on rfc4742. If the work on
   rfc4741bis uncovers any additional fixes/clarifications that need
   to be made to rfc4742, the WG may consider to also do a rfc4742bis
   as part of this work-item.

The following items have been identified as important but are currently
not considered in scope for re-chartering and may be candidates for work
when there is community consensus to take them on:

- NETCONF Notification content
- Access Control requirements
- NETCONF access to SMI-based MIB data

Goals and Milestones:
Done   Working Group formed
Done   Submit initial Netconf Protocol draft
Done   Submit initial Netconf over (transport-TBD) draft
Done   Begin Working Group Last Call for the Netconf Protocol draft
Done   Begin Working Group Last Call for the Netconf over
(transport-TBD)
            draft
Done   Submit final version of the Netconf Protocol draft to the IESG
Done   Submit final version of the Netconf over SOAP draft to the IESG
Done   Submit final version of the Netconf over BEEP draft to the IESG
Done   Submit final version of the Netconf over SSH draft to the IESG
Done   Update charter
Done   Submit first version of NETCONF Notifications document
Done   Begin WGLC of NETCONF Notifications document
Done   Submit final version of NETCONF Notifications document to IESG
            for consideration as Proposed Standard
Done   -00 draft for fine Grain Locking
Done   -00 draft for NETCONF over TLS
Done   -00 draft for NETCONF Monitoring
Done   -00 draft for Schema Advertisement
Done   Early Review of client authentication approach (for NETCONF over
            TLS) with the security community at IETF 71
N.A.     WG Last Call on Schema Advertisement after IETF72
            Schema Advertisement has been merged into Monitoring
Done    WG Last Call on NETCONF over TLS after IETF72
Done    Netconf over TLS to IESG for consideration as Proposed Standards
Dec 2008  WG Last Call on Fine Grain Locking after IETF73
Dec 2008  Send Partial Locking to IESG for consideration as Proposed
Standards
Jan 2009   Initial WG draft for with-defaults capability
Feb 2009   Initial WG draft for rfc4741bis
Mar 2009   WG Last Call on NETCONF Monitoring after IETF73
Apr 2009   WG Last Call on rfc4741bis
Apr 2009   WG Last Call on with-defaults
Jun 2009   rfc4741bis to IESG for considerations as Proposed Standard
Jun 2009   with-defaults capability to IESG for coise which protocol features are supported on a particular
   netconf-capable device. However, there is currently no way to
discover
   which XML Schema are supported on the device. The NETCONF working
   group will produce a standards-track RFC with mechanisms making this
   discovery possible (this item may be merged with "NETCONF monitoring"
   into a single document).

   Note: The schema-advertisement material has been merged into the
   NETCONF monitoring document based on WG consensus.

4. NETCONF over TLS: Based on implementation experience there is a
   need for a standards track document to define NETCONF over TLS as an
   optional transport for the NETCONF protocol.

5. NETCONF default handling: NETCONF today does not define whether
   default values should be returned by the server in replies
   to requests for reading configuration and state data. Different
   clients have different needs to receive or not to receive
   default data. The NETCONF working group will produce a
   standards-track RFC defining a mechanism that allows
   NETCONF clients to control whether default data is returned
   by the netconf server.

6. NETCONF implementations have shown that the specification in RFC4741
   is not 100% clear and has lead to different interpretations and
implementations. 
   Also some errors have been uncovered. So the WG will do an rfc4741bis
with
   following constraints:

     - bug fixes are to be done
     - clarifications can be done
     - no extensions (i.e. we are not doing a NETCONF V2)
     - The work can be started based on the discussion in IETF #73 (see
        http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf).

   Note: A technical errata has been posted on rfc4742. If the work on
   rfc4741bis uncovers any additional fixes/clarifications that need
   to be made to rfc4742, the WG may consider to also do a rfc4742bis
   as part of this work-item.

The following items have been identified as important but are currently
not considered in scope for re-chartering and may be candidates for work
when there is community consensus to take them on:

- NETCONF Notification content
- Access Control requirements
- NETCONF access to SMI-based MIB data

Goals and Milestones:
Done   Working Group formed
Done   Submit initial Netconf Protocol draft
Done   Submit initial Netconf over (transport-TBD) draft
Done   Begin Working Group Last Call for the Netconf Protocol draft
Done   Begin Working Group Last Call for the Netconf over
(transport-TBD)
            draft
Done   Submit final version of the Netconf Protocol draft to the IESG
Done   Submit final version of the Netconf over SOAP draft to the IESG
Done   Submit final version of the Netconf over BEEP draft to the IESG
Done   Submit final version of the Netconf over SSH draft to the IESG
Done   Update charter
Done   Submit first version of NETCONF Notifications document
Done   Begin WGLC of NETCONF Notifications document
Done   Submit final version of NETCONF Notifications document to IESG
            for consideration as Proposed Standard
Done   -00 draft for fine Grain Locking
Done   -00 draft for NETCONF over TLS
Done   -00 draft for NETCONF Monitoring
Done   -00 draft for Schema Advertisement
Done   Early Review of client authentication approach (for NETCONF over
            TLS) with the security community at IETF 71
N.A.     WG Last Call on Schema Advertisement after IETF72
            Schema Advertisement has been merged into Monitoring
Done    WG Last Call on NETCONF over TLS after IETF72
Done    Netconf over TLS to IESG for consideration as Proposed Standards
Dec 2008  WG Last Call on Fine Grain Locking after IETF73
Dec 2008  Send Partial Locking to IESG for consideration as Proposed
Standards
Jan 2009   Initial WG draft for with-defaults capability
Feb 2009   Initial WG draft for rfc4741bis
Mar 2009   WG Last Call on NETCONF Monitoring after IETF73
Apr 2009   WG Last Call on rfc4741bis
Apr 2009   WG Last Call on with-defaults
Jun 2009   rfc4741bis to IESG for considerations as Proposed Standard
Jun 2009   with-defaults capability to IESG nsiderations as
Proposed Standard
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Dec 2008 17:40:52 +0100

I would suggest that we let a few days for the WG members to read and
raise objections if any, before bringing this to the IESG for approval.
If I am not mistaken it is the firs time the new charter text is
distributed on the list. 

Dan

> -----Original Message-----
> From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]] 
> Sent: Thursday, December 11, 2008 6:29 PM
> To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> Subject: Request for charter change
> 
> 
> Dear ADs (and WG),
> 
> text be posted as our current WG charter page and forward it 
> to iesg-secretary if approve <<081211_NETCONF WG Charter 
> text.txt>> d <<Diff WGCharter-20080821-WGCharter-20081211.htm>> ? 
>   
> Thank you.
> 
> Bert and Mehmet
> 
> Configuration of networks of devices has become a critiFrom [email-masked]  Thu Dec 11 08:41:04 2008
Content-class: urn:content-classes:message
Date: Thu, 11 Dec 2008 17:40:52 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>,
	<[email-masked]>, <[email-masked]>
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

I would suggest that we let a few days for the WG members to read and
raise objections if any, before bringing this to the IESG for approval.
If I am not mistaken it is the firs time the new charter text is
distributed on the list. 

Dan

> -----Original Message-----
> From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]] 
> Sent: Thursday, December 11, 2008 6:29 PM
> To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> Subject: Request for charter change
> 
> 
> Dear ADs (and WG),
> 
> text be posted as our current WG charter page and forward it 
> to iesg-secretary if approve <<081211_NETCONF WG Charter 
> text.txt>> d <<Diff WGCharter-20080821-WGCharter-20081211.htm>> ? 
>   
> Thank you.
> 
> Bert and Mehmet
> 
> Configuration of networks of devices has become acal 
> requirement for operators in today's highly interoperable 
> networks. Operators from large to small have developed their 
> own mechanisms or used vendor specific mechanisms to transfer 
> configuration data to and from a device, and for examining 
> device state information which may impact the configuration. 
> Each of these mechanisms may be different in various aspects, 
> such as session establishment, user authentication, 
> The NETCONF Working Group is chartered to produce a protocol 
> suitable for network configuration, with the following 
> characteristics:
> 
> The NETCONF protocol is using XML for data encoding purposes, 
> because XML is a widely deployed standard which is supported 
> by a large number of applications.
> 
> The NETCONF protocol should be independent of the data 
> definition language and data models used to describe 
> configuration and state data.
> 
> However, the authorization model used in the protocol is 
> dependent on the data model. Although these issues must be 
> fully addressed to develop standard data models, only a small 
> part of this work will be initially addressed. This group 
> will specify requirements for standard data models in order 
> to fully support the NETCONF protocol, such as:
> 
> - identification of principals, such as user names or 
> distinguished names
> The initial work started in 2003 and has already been 
> completed and was restricted to following items:
> 
>   a) NETCONF Protocol Specification, which defines the 
> operational model,
> In the current phase of the incremental development of 
> NETCONF the workgroup will focus on following items:
> 
> 2. NETCONF monitoring: It is considered best critical 
> requirement for operators in today's highly interoperable 
> networks. Operators from large to small have developed their 
> own mechanisms or used vendor specific mechanisms to transfer 
> configuration data to and from a device, and for examining 
> device state information which may impact the configuration. 
> Each of these mechanisms may be different in various aspects, 
> such as session establishment, user authentication, 
> The NETCONF Working Group is chartered to produce a protocol 
> suitable for network configuration, with the following 
> characteristics:
> 
> The NETCONF protocol is using XML for data encoding purposes, 
> because XML is a widely deployed standard which is supported 
> by a large number of applications.
> 
> The NETCONF protocol should be independent of the data 
> definition language and data models used to describe 
> configuration and state data.
> 
> However, the authorization model used in the protocol is 
> dependent on the data model. Although these issues must be 
> fully addressed to develop standard data models, only a small 
> part of this work will be initially addressed. This group 
> will specify requirements for standard data models in order 
> to fully support the NETCONF protocol, such as:
> 
> - identification of principals, such as user names or 
> distinguished names
> The initial work started in 2003 and has already been 
> completed and was restricted to following items:
> 
>   a) NETCONF Protocol Specification, which defines the 
> operational model,
> In the current phase of the incremental development of 
> NETCONF the workgroup will focus on following items:
> 
>    advertise which protocol features are supported on a particular
>    netconf-capable device. However, there is currently no way 
> to discover
>    is not 100% clear and has lead to different 
> interpretations and implementations. 
>    Also some errors have been uncovered. So the WG will do an 
> rfc4741bis with
>    following constraints:
> 
> The following items have been identified as important but are 
> currently not considered in scope for re-chartering and may 
> be candidates for work when there is community consensus to 
> take them on:
> 
> Dec 2008  WG Last Call on Fine Grain Locking after IETF73 Dec 
> 2008  Send Partial Locking to IESG for consideration as 
> Proposed Standards
> Jun 2009   with-defaults capability to IESG for considerations as
> Proposed Standard
> 

 practice for IETF working
>    advertise which protocol features are supported on a particular
>    netconf-capable device. However, there is currently no way 
> to discover
>    is not 100% clear and has lead to different 
> interpretations and implementations. 
>    Also some errors have been uncovered. So the WG will do an 
> rfc4741bis with
>    following constraints:
> 
> The following items have been identified as important but are 
> currently not considered in scope for re-chartering and may 
> be candidates for work when there is community consensus to 
> take them on:
> 
> Dec 2008  WG Last Call on Fine Grain Locking after IETF73 Dec 
> 2008  Send Partial Locking to IESG for consideration as 
> Proposed Standards
> Jun 2009   with-defaults capability to IESG for considerations as
> Proposed Standard
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Dec 2008 10:24:36 -0800

> for the NETCONF WG charter. 

...

>    Also some errors have been uncovered. So the WG will do an rfc4741bis

Please document the implementation experience first,
before changing the protocol based on it.  I believe
there was 1 interop test done awhile back, and Juergen
has done some private testing on his own.

What level of interoperability is the WG trying to achieve?
Is it the RPC operation layer? The content layer?
Are there multiple independent implementations of the
same read-write data model(s)?

Is the WG attempting to gather interoperability experience,
document it, and advance the protocol to Draft Standard?
Is the WG ready to move some transports to Historic if
there are not at least 2 independent implementations?

If not, why not?
It's been published for 2 years already.
When does the WG estimate that NETCONF will advance to DS?

>      - no extensions (i.e. we are not doing a NETCONF V2)

What about the 'test-only' enumeration for test-option?
IMO, the WG needs some flexibility in the solution space
to deal with usability problems found.  It has been determined
that 'test-then-set' and <validate> are somewhat worthless,
and a 'test-only' mode for <edit-config> would have been much
better in the first place.  Is that a new feature or a bugfix?

Is the WG allowed to make non-backward-compatible changes
to the protocol or transports?

The base URI for the NETCONF protocol is going to change
(it better) if any observable changes are made to protocol
behavior.  Are there any 1.0 to 1.1 protocol migration
concerns?  Are there any issues related to mixing 1.0
and 1.1 agents in the same network?

IMO, this 4741-bis work item does not fully address the
scope and complexity of the problem space.

thanks,
Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Dec 2008 10:24:36 -0800

...

If not, why not?

thanks,
Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Dec 2008 19:32:28 +0100

Andy,

Some of the issues that you are mentioning have been discussed in
Minneapolis. I believe that the chairs have made a reasonable effort to
catch the consensus in Minneapolis, which of course needs to be
confirmed by this discussion.  

> to the protocol or transports?

 If we answer here is 'yes' then we must recycle at PS and it will more
look like a 2.0 than a 1.1

BTW - we talk about the protocol in 4741bis, not sure what you mention
transports. 

Dan
(speaking as contributor)

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Thursday, December 11, 2008 8:25 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> > based on the consensus after IETF 73 we prepared an update for the 
> > NETCONF WG charter.
> > 
> 
> 
> ...
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Dec 2008 19:32:28 +0100

Andy,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Dec 2008 20:24:59 +0100

> has done some private testing on his own.

I will post a report shortly providing a high level overview of the
testing we have done so far. In short, we have written a test suite in
Python using the Python unit testing framework. And yes, we love to
get more implementations to test - so far we had three independent
impementations under test and I sure there are more implementations
out there.

> same read-write data model(s)?

Right now, some tests are duplicated for the different data models
boxes support. Right after the interim, I wrote together with Martin a
YANG model for VACM and we have test cases against this data model. We
hope that implementors can support this VACM data model so that we
have a common data model for edit-config tests.

In short, we try to test the messaging (hello and rpc messages), the
operations and their features (filtering etc.) and to a lesser extend
at the moment data model specifics (due to a lack of common data
models).

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Dec 2008 20:24:59 +0100

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Dec 2008 13:13:35 -0800

> look like a 2.0 than a 1.1

I don't mind cycling at Proposed Standard, but I do mind
wasting a revision cycle (which is N years in the IETF)
on fixing typos and clarifying text if the WG decides
that some of the functionality itself needs to be updated.

I do not want to introduce hack-based design into
the NETCONF protocol.  If it changes AT ALL, then
the capability URI needs to be updated.
The option of 'leave the version the same and
NETCONF peers can just guess what the other side
really implements' is not a good plan.

I am glad there are going to be 2 interoperability test
reports to start wiFrom [email-masked]  Fri Dec 12 13:13:48 2008
Date: Fri, 12 Dec 2008 13:13:35 -0800
From: Andy Bierman <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

> look like a 2.0 than a 1.1

I don't mind cycling at Proposed Standard, but I do mind
wasting a revision cycle (which is N years in the IETF)
on fixing typos and clarifying text if the WG decides
that some of the functionality itself needs to be updated.

I do not want to introduce hack-based design into
the NETCONF protocol.  If it changes AT ALL, then
the capability URI needs to be updated.
The option of 'leave the version the same and
NETCONF peers can just guess what the other side
really implements' is not a good plan.

I am glad there are going to be 2 interoperability test
reports to stth.  The charter should include an
issue (or sentence) saying that the WG will address any
1.0 and 1.1 co-existence issues as well.

> BTW - we talk about the protocol in 4741bis, not sure what you mention

There has been some talk of removing the SSH EOM marker,
and that would be an incompatible change in 4742.  The charter does
mention that 4742 may get updated as well.

Andy

art with.  The charter should include an
issue (or sentence) saying that the WG will address any
1.0 and 1.1 co-existence issues as well.

> BTW - we talk about the protocol in 4741bis, not sure what you mention

There has been some talk of removing the SSH EOM marker,
and that would be an incompatible change in 4742.  The charter does
mention that 4742 may get updated as well.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Dec 2008 22:30:07 +0100

On Fri, Dec 12, 2008 at 01:13:35PM -0800, Andy Bierman wrote:

> the NETCONF protocol.

Who proposed to do that?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Dec 2008 22:30:07 +0100

Who proposed to do that?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Dec 2008 15:13:59 -0800

>> I do not want to introduce hack-based design into

Nobody, because nobody is going to suggest that we should
leave the base capability URI the same if a compliant 1.0
manager or agent is not 1.1 compliant as well.

If there is no 1.1 URI, then there is no 1.1 protocol,
just clarifying non-changes.  However, the IETF has been
known to stretch the meaning of a clarifying non-change,
which IMO is wrong.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Dec 2008 15:13:59 -0800

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 14 Dec 2008 11:45:31 +0100 (CET)

Hi,

> better in the first place.  Is that a new feature or a bugfix?

This particular case could be handled by incrementing the minor
version for the :validate capability so that the URI is:

  urn:ietf:params:netconf:capability:validate:1.1

This 1.1 version is backwards compatible, but an old client will not
understand that, so a server that wants to support both old and new
clients would advertise both versions:

  urn:ietf:params:netconf:capability:validate:1.0
  urn:ietf:params:netconf:capability:validate:1.1

The proposed charter text says:

I guess this would be an extension, but it's not really "netconf v2".

> behavior.

I don't think that any changes has been proposed that would affect the
base capability.  *maybe* some subtree filtering changes could fall
into this category.

> Are there any 1.0 to 1.1 protocol migration
> concerns?From [email-masked]  Sun Dec 14 02:45:43 2008
Date: Sun, 14 Dec 2008 11:45:31 +0100 (CET)
To: [email-masked]
From: Martin Bjorklund <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

Hi,

> better in the first place.  Is that a new feature or a bugfix?

This particular case could be handled by incrementing the minor
version for the :validate capability so that the URI is:

  urn:ietf:params:netconf:capability:validate:1.1

This 1.1 version is backwards compatible, but an old client will not
understand that, so a server that wants to support both old and new
clients would advertise both versions:

  urn:ietf:params:netconf:capability:validate:1.0
  urn:ietf:params:netconf:capability:validate:1.1

The proposed charter text says:

I guess this would be an extension, but it's not really "netconf v2".

> behavior.

I don't think that any changes has been proposed that would affect the
base capability.  *maybe* some subtree filtering changes could fall
into this category.

> Are there any 1.0 to 1.1 protocol migration

I'm not sure I understand this - do you want to see such changes, or
are you worried that the charter allows such changes?

/martin

  Are there any issues related to mixing 1.0
> scope and complexity of the problem space.

I'm not sure I understand this - do you want to see such changes, or
are you worried that the charter allows such changes?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Dec 2008 05:30:07 -0800

>   urn:ietf:params:netconf:capability:validate:1.1

There are lots of ways the protocol could get changed,
such as addingFrom [email-masked]  Sun Dec 14 05:30:19 2008
Date: Sun, 14 Dec 2008 05:30:07 -0800
From: Andy Bierman <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

>   urn:ietf:params:netconf:capability:validate:1.1

There are lots of ways the protocol could get changed,
such as  new capabilities, without bumping
the base capability.  What matters is whether the 1.0
client continues to work even though it does
not know about these new capabilities.

> are you worried that the charter allows such changes?

If the IESG is happy with the charter, then fine.
It looks a bit unclear to me.  IMO it is a waste
of 2 - 3 years work to cycle at Proposed Standard for
a few penny-ante tweaks and bug-fixes.

Andy

adding new capabilities, without bumping
the base capability.  What matters is whether the 1.0
client continues to work even though it does
not know about these new capabilities.

> are you worried that the charter allows such changes?

If the IESG is happy with the charter, then fine.
It looks a bit unclear to me.  IMO it is a waste
of 2 - 3 years work to cycle at Proposed Standard for
a few penny-ante tweaks and bug-fixes.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 14 Dec 2008 14:57:51 +0100

On Sun, Dec 14, 2008 at 05:30:07AM -0800, Andy Bierman wrote:

> IMO it is a waste of 2 - 3 years work to cycle at Proposed Standard
> for a few penny-ante tweaks and bug-fixes.

It takes 2-3 if _we_ make it take 2-3 years. The charter has a much
shorter time plan and it is up to us to stick to it.

Our testing experience is that there are things that implementors have
done differently and I believe we do this exercise with the goal to
improve and document interoperability. I believe this is worth it.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 14 Dec 2008 14:57:51 +0100

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Dec 2008 06:30:30 -0800

> improve and document interoperability. I believe this is worth it.

IMO, lots of protocol versions (and capability-based variants)
over the years has a high cost.  In the long run, lots of little
versions aren't really better that 2 or 3 big versions.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Dec 2008 06:30:30 -0800

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Dec 2008 07:16:02 -0800

...
> I guess this would be an extension, but it's not really "netconf v2".

I do not understand the premise of this statement,
or real purpose of this charter.  Why are extensions
to the protocol bad, but optional capabilities are good?

Is the purpose of the charter to clarify the document without
changing the protocol, or to make both the document and
the protocol better?

Several NMS developers (including our former NETMOD co-Chair)
have stated in the past that optional agent features are not
that useful to them.  NETCONF seems to be very agent-centric,
focusing on flexibility rather than avoiding it.

In the long run, 200 permutations of a feature set has its drawbacks,
especially wrt/ NMS complexity and a large, complicated document set.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Dec 2008 07:16:02 -0800

...

Andy

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 14 Dec 2008 17:43:12 +0100

The PURSPOSE of the charter is to CLARIFY things that have
caused variations of implementation (because of mis-understanding)
and to FIX any BUGS that we have uncovered.
And as such, we have set ourselves a ratehr SHORT TIMELINE,
namely we want to submit to thge IESG by JUNE 2009!

That is how I (for one) understood the consensus we had at IETF73
and as it was confirmed (or not opposed) on the mailing list.

Bert

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 14 Dec 2008 17:43:12 +0100

Bert

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 14 Dec 2008 17:39:14 +0100

Exactly.
Andy, do you want to add to the charter:

    If the WG turns out not to get consensus on the new document by June 2009,
    then we will abolish the effort at that time.

That would make it clear to everyone that we're are NOT going to drag this piece of
work out forever. I am willing to take responsibility for that as one of the co-chairs.

If we (that is the WG) are eager to do what we set out to do, then it should NOT drag out.

Bert
  ----- Original Message ----- 
  From: Juergen Schoenwaelder 
  To: Andy Bierman 
  Cc: [email-masked] ; [email-masked] 
  Sent: Sunday, December 14, 2008 2:57 PM
  Subject: Re: [Netconf] Request for charter change

  > IMO it is a waste of 2 - 3 years work to cycle at Proposed Standard
 From [email-masked]  Sun Dec 14 09:04:29 2008
From: "Bert Wijnen \(IETF\)" <[email-masked]>
To: <[email-masked]>,
	"Andy Bierman" <[email-masked]>
Date: Sun, 14 Dec 2008 17:39:14 +0100
Organization: Consultant
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

This is a multi-part message in MIME format.
Exactly.
Andy, do you want to add to the charter:

    If the WG turns out not to get consensus on the new document by June 2009,
    then we will abolish the effort at that time.

That would make it clear to everyone that we're are NOT going to drag this piece of
work out forever. I am willing to take responsibility for that as one of the co-chairs.

If we (that is the WG) are eager to do what we set out to do, then it should NOT drag out.

Bert
  ----- Original Message ----- 
  From: Juergen Schoenwaelder 
  To: Andy Bierman 
  Cc: [email-masked] ; [email-masked] 
  Sent: Sunday, December 14, 2008 2:57 PM
  Subject: Re: [Netconf] Request for charter change

  On Sun, Dec 14, 2008 at 05:30:07AM -0800, Andy Bierman wrote:

  > for > for a few penny-ante tweaks and bug-fixes.

  /js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Dec 2008 09:50:26 -0800

>     then we will abolish the effort at that time.

No, I do not want to add artificial deadlines to the charter.
I never really got an answer on the very real corner-case
(test-only enum), if this is in scope for 4741-bis or
is this going to be (yet another) little optional capability
added in the future.

Of course it is good to have the NETCONF protocol be as
clear as possible for everybody to understand.  Publishing
a 4741-bis is just one way to fix errata and clarify
details.  Some WGs use an Implementation Guidelines RFC
for that purpose, for example.

I prefer a 2 year effort to produce NETCONF 2.0,
starting some time after NETMOD is done, instead of a 'small-as-possible'
update to NETCONF 1.0.  I think we will find opportunities
for protocol improvement as more YANG content is implemented.

I do not object to the current charter, because with Bert in charge,
there isn't going to be any missed milestones.  I do not think
the WG will have any problem finishing 4741-bis before YANG is
done, but I'm not so sure about RFC publication.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Dec 2008 09:50:26 -0800

Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 14 Dec 2008 20:07:41 +0100

Dear NETCONF Members,

Dan agreed to bring the charter update proposal to the IESG 
telechat on 12/18 to enable the approval before Christmas.

Please speak up if you disagree with the proposed new charter 
text by 12/16 5pm ET.

Cheers, 
Mehmet

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Ersue, 
> Mehmet (NSN - DE/Munich)
> Sent: Thursday, December 11, 2008 5:29 PM
> To: ext Romascanu, Dan (Dan); [email-masked]; [email-masked]
> specific mechanisms to transfer configuration data to and from a
> rfc4741bis
> currently

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 14 Dec 2008 20:07:41 +0100

Dear NETCONF Members,

Cheers, 
Mehmet

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 14 Dec 2008 22:24:58 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> such as adding new capabilities, without bumping

So is your opinion that the proposed charter text allows us to bump
the version of this (or other) capability?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 14 Dec 2008 22:24:58 +0100 (CET)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Dec 2008 15:27:48 -0800

Martin Bjorklund wrote:
>>>   urn:ietf:paramFrom [email-masked]  Sun Dec 14 15:28:01 2008
Date: Sun, 14 Dec 2008 15:27:48 -0800

Martin Bjorklund wrote:
>>>   urn:ietfs:netconf:capability:validate:1.1
>>>

I am not as thrilled with the "base + capabilities" model
as I used to be.

A new capability cannot change the contract of an old capability.
In theory anyways.  It didn't work out that way for :xpath,
but it could for other capabilities.

Perhaps people are unfamiliar with the "no options" logic:

A) If FOO is an optional feature, I cannot count on it being
    implemented on all the platforms I need to support.

B) Since FOO is optional and I cannot count on it, how important
    is the feature anyway?

C) If it's some minor knob that every platform can do without,
    then what is the value to me to spend any effort to implement
    the knob at all?

D) If it's some major feature, that I cannot do without, then
    I must invest in some workaround (hopefully) that all platforms
    can support.

E) If I have invest in a widely supported work-around, why should
    I also invest in implementing the optional way of doing the
    same thing (i.e., FOO).

 From this perspective, capabilities such as :url, :validate,
:rollback-on-error, :confirmed-commit, :xpath, :interleave,
or even :notifications do not seem so helpful.

Andy

:params:netconf:capability:validate:1.1
> the version of this (or other) capability?

I am not as thrilled with the "base + capabilities" model
as I used to be.

A new capability cannot change the contract of an old capability.
In theory anyways.  It didn't work out that way for :xpath,
but it could for other capabilities.

Perhaps people are unfamiliar with the "no options" logic:

A) If FOO is an optional feature, I cannot count on it being
    implemented on all the platforms I need to support.

B) Since FOO is optional and I cannot count on it, how important
    is the feature anyway?

C) If it's some minor knob that every platform can do without,
    then what is the value to me to spend any effort to implement
    the knob at all?

D) If it's some major feature, that I cannot do without, then
    I must invest in some workaround (hopefully) that all platforms
    can support.

E) If I have invest in a widely supported work-around, why should
    I also invest in implementing the optional way of doing the
    same thing (i.e., FOO).

 From this perspective, capabilities such as :url, :validate,
:rollback-on-error, :confirmed-commit, :xpath, :interleave,
or even :notifications do not seem so helpful.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Dec 2008 08:32:24 +0100

> Perhaps people are unfamiliar with the "no options" logic:

[...]

> or even :notifications do not seem so helpful.

There is also the other extreme where everybody claims to implement a
complex standard but in reality only different subsets are supported.

While I agree with you that we should not create too many little
capabilities (understanding all the possible interactions alone is
becoming difficult), I believe a set of well defined caFrom [email-masked]  Sun Dec 14 23:32:41 2008
Date: Mon, 15 Dec 2008 08:32:24 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Andy Bierman <[email-masked]>
Mail-Followup-To: Andy Bierman <[email-masked]>,
	Martin Bjorklund <[email-masked]>, [email-masked],
	[email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] Request for charter change
Reply-To: [email-masked]
Sender: [email-masked]

> Perhaps people are unfamiliar with the "no options" logic:

[...]

> or even :notifications do not seem so helpful.

There is also the other extreme where everybody claims to implement a
complex standard but in reality only different subsets are supported.

While I agree with you that we should not create too many little
capabilities (understanding all the possible interactions alone is
becoming difficult), I believe a set of well defined capabilipabilities is
not a bad thing.

/js

ties is
not a bad thing.

/js

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Tue, 16 Dec 2008 10:17:27 +0100

Hi,

I have a few objections regarding this text. It may mislead unfamiliar readers.

> - Supports integration with existing user authentication methods

How? Leaving authentication for the underlying transport protocol is a support? It rather means
"We don't care how authentication is performed", however "NETCONF connection must be authenticated".

> - Supports integration with existing configuration database systems

How? Which existing databases? Could you give the names? There is no one word about it.

>   as locking and rollback capability)

How? Telling "we give you possibility to advertise rollback-on-error
capability but it's your problem to implement underlying transaction mechanism" is a support?
Why NETCONF boast about locking but From [email-masked]  Tue Dec 16 01:20:11 2008
Date: Tue, 16 Dec 2008 10:17:27 +0100
From: Tomasz Mikolajczyk <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

Hi,

I have a few objections regarding this text. It may mislead unfamiliar readers.

> - Supports integration with existing user authentication methods

How? Leaving authentication for the underlying transport protocol is a support? It rather means
"We don't care how authentication is performed", however "NETCONF connection must be authenticated".

> - Supports integration with existing configuration database systems

How? Which existing databases? Could you give the names? There is no one word about it.

>   as locking and rollback capability)

How? Telling "we give you possibility to advertise rollback-on-error
capability but it's your problem to implement underlying transaction mechanism" is a support?
Why NETCONF boast about lockindoesn't say anything about isolation or about the whole ACID properties?
Maybe because isolation is the underlying transaction implementation matter. But the same as locking/unlocking.
I omit fact that specified unlock operation is illogical (it was described in many my posts in the past).

IMO, defining a custom capability with the operations like:
 - open-transaction-on-configuration
 - commit-configuration
 - rollback-configuration

would be much clearer and is the same level of "support" for transactions like the existing one. Moreover, when you are able to
call this operations using other protocol managers (for instance CLI) why you need NETCONF? Where is this
support for transactions? I don't agree NETCONF supports them. Too big words.

>    fine-grain locking of the NETCONF configuration datastore.

IMO, First of all the existing unlock should be corrected before new features are introduced.

>         http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf).

What about default value of the <test-option>. IMO, the default one should be "set". I explained it in my posts.
Martin said that's not a bug. The question is if a mistake is a bug or not.

Regards,
Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

g but doesn't say anything about isolation or about the whole ACID properties?
Maybe because isolation is the underlying transaction implementation matter. But the same as locking/unlocking.
I omit fact that specified unlock operation is illogical (it was described in many my posts in the past).

IMO, defining a custom capability with the operations like:
 - open-transaction-on-configuration
 - commit-configuration
 - rollback-configuration

would be much clearer and is the same level of "support" for transactions like the existing one. Moreover, when you are able to
call this operations using other protocol managers (for instance CLI) why you need NETCONF? Where is this
support for transactions? I don't agree NETCONF supports them. Too big words.

>    fine-grain locking of the NETCONF configuration datastore.

IMO, First of all the existing unlock should be corrected before new features are introduced.

>         http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf).

What about default value of the <test-option>. IMO, the default one should be "set". I explained it in my posts.
Martin said that's not a bug. The question is if a mistake is a bug or not.

Regards,
Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 16 Dec 2008 11:22:49 +0100

Tomasz, can you try to get rid of your email trailer.
It says that your posting is CONFIDENTIAL. AS you MUST/SHOULD know from the
NOTE WELL, there is NOTHING CONFIDENTIAL on any IETF mailing list.

W.r.t. to your comments:

- most of it is about already completed WG work items. We do NOT intend to
  change any charter text in that space.
- the piece that is about the rfc4741bis, your topic is one that can be discussed
  as part of the WG deliberations on the topic. We do not have to explicitly list
  all items that can/will be discussed in the WG.

So I see no objections that we need to take into account.

Bert
  ----- Original Message ----- 
  From: Tomasz Mikolajczyk 
  To: Ersue, Mehmet (NSN - DE/Munich) 
  Cc: [email-masked] ; [email-masked] 
  Sent: Tuesday, December 16, 2008 10:17 AM
  Subject: Re: [Netconf] Request for charter change

  Hi,

  Why NETCONF boast about locking but doesn't say anything about isolation or about the whole ACID properties?

  Regards,
  Tomasz

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 16 Dec 2008 11:22:49 +0100

W.r.t. to your comments:

Bert
  ----- Original Message ----- 
  From: Tomasz Mikolajczyk 
  To: Ersue, Mehmet (NSN - DE/Munich) 
  Cc: [email-masked] ; [email-masked] 
  Sent: Tuesday, December 16, 2008 10:17 AM
  Subject: Re: [Netconf] Request for charter change

  Hi,

  Regards,
  Tomasz

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Dec 2008 08:33:29 -0800

Tomasz Mikolajczyk wrote:
...
> Martin said that's not a bug. The question is if a mistake is a bug or not.

I think the test-option parameter needs a lot of work.
The most useful value (test-only) is not there.
Both values that are defined are unclear,
and the default is wrong.

The default that makes sense is target-dependent.
For candidate, the default needs to be 'set'.

For running, the only value can be 'test-then-set'.
The value 'set' should do the same as 'test-then-set'.
The manager cannot ask the agent to leave the running config
in an invalid state.  That's only for the candidate config.

I think Martin's suggestion about a :validate.1.1 capability
will work fine for test-only, because it is a pure extension,
and that is what capabilities were designed to address.
(Not the creeping :xpath or :url design!)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Dec 2008 08:33:29 -0800

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Dec 2008 18:26:09 +0100 (CET)

> will work fine for test-only, because it is a pure extension,

So maybe the proposed charter text:

can be changed to "extensions can be done only when needed to fix bugs
or inconsistencies" or something similar.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Dec 2008 18:26:09 +0100 (CET)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Dec 2008 09:39:24 -0800

> or inconsistencies" or something similar.

That would make me very happy.
I want to address real interoperability issues, even if
that means changing 1.0 in a non-backward compatible way.
You reminded me that we have lots of capabilities besides
the base capability that can be incremented.

Of course, the default is not to add or change anything,
and there are very few actual changes actually proposed.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Dec 2008 09:39:24 -0800

Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 16 Dec 2008 22:52:44 +0100

> that means changing 1.0 in a non-backward compatible way.

Whether chanFrom [email-masked]  Tue Dec 16 13:53:01 2008
Content-class: urn:content-classes:message
Date: Tue, 16 Dec 2008 22:52:44 +0100
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Andy Bierman" <[email-masked]>,
	"Martin Bjorklund" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

> that means changing 1.0 in a non-backward compatible way.

Whetheging 1.0 in a non-backward compatible way is 
really needed has to be discussed and decided by the WG. 
This is not excluded by the proposed charter text.

Current charter text proposal says:
     - bug fixes are to be done
     - clarifications can be done
     - no extensions (i.e. we are not doing a NETCONF V2)

The bullets above include IMO also fixing inconsistencies.

How about changing the third bullet above to:
     - extensions can be done only when needed to fix bugs 
       or inconsistencies (i.e. we are not doing a NETCONF V2)

With this text the WG needs to discuss to find out which 
extensions are fixes to inconsistencies and do not produce 
a NETCONF V2.

Mehmet

r changing 1.0 in a non-backward compatible way is 
really needed has to be discussed and decided by the WG. 
This is not excluded by the proposed charter text.

Current charter text proposal says:
     - bug fixes are to be done
     - clarifications can be done
     - no extensions (i.e. we are not doing a NETCONF V2)

The bullets above include IMO also fixing inconsistencies.

How about changing the third bullet above to:
     - extensions can be done only when needed to fix bugs 
       or inconsistencies (i.e. we are not doing a NETCONF V2)

With this text the WG needs to discuss to find out which 
extensions are fixes to inconsistencies and do not produce 
a NETCONF V2.

Mehmet

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 17 Dec 2008 00:31:35 +0100

Hi Dan, Ron,

we think we have WG consensus now for the updated 
charter text. 

We would like to ask you to bring it to the IESG telechat 
on 12/18.

Thanks.

Bert & Mehmet

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 17 Dec 2008 00:31:35 +0100

Hi Dan, Ron,

Thanks.

Bert & Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Dec 2008 08:09:51 -0800

Ersue, Mehmet (NSN - DE/Munich) wrote:
> Whether changing 1.0 in a non-backward compatible way is 

not sure what has already been decided, but the charter
text is OK.

IMO, there are some little details in NETCONF that
should be done over because they do not fit with
the way YANG (and later on NETCONF ACM)From [email-masked]  Thu Dec 18 08:10:06 2008
Date: Thu, 18 Dec 2008 08:09:51 -0800
From: Andy Bierman <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

Ersue, Mehmet (NSN - DE/Munich) wrote:
> Whether changing 1.0 in a non-backward compatible way is 

not sure what has already been decided, but the charter
text is OK.

IMO, there are some little details in NETCONF that
should be done over because they do not fit with
the way YANG (and later on NETCON expects
to organize data.  This won't happen because it
would require a base-capability change, but these
corner-cases should be addressed at some point:

   - use of attributes as parameters in <get>, <get-config>.
     A much better design would have been to use a choice
     between an xpath-filter leaf and a subtree-filter leaf.

   - use of a capability on 1 value of enumeration in <edit-config>
     parameters (:rollback-on-error).  A much better design
     would have been a separate conditional leaf (like test-option).

Andy

F ACM) expects
to organize data.  This won't happen because it
would require a base-capability change, but these
corner-cases should be addressed at some point:

   - use of attributes as parameters in <get>, <get-config>.
     A much better design would have been to use a choice
     between an xpath-filter leaf and a subtree-filter leaf.

   - use of a capability on 1 value of enumeration in <edit-config>
     parameters (:rollback-on-error).  A much better design
     would have been a separate conditional leaf (like test-option).

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 23 Dec 2008 00:32:42 -0500

THAT looks like a slippery slope ...

dbh 

> [mailto:[email-masked]] On Behalf Of Ersue, Mehmet 
> (NSN - DE/Munich)
> Sent: Tuesday, December 16, 2008 4:53 PM
> To: ext Andy Bierman; Martin Bjorklund
> Cc: [email-masked]
> > I want to address real interopeFrom [email-masked]  Mon Dec 22 21:32:54 2008
From: "David B Harrington" <[email-masked]>
To: "'Ersue, Mehmet \(NSN - DE/Munich\)'" <[email-masked]>,
	"'ext Andy Bierman'" <[email-masked]>,
	"'Martin Bjorklund'" <[email-masked]>
Date: Tue, 23 Dec 2008 00:32:42 -0500
Cc: [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

THAT looks like a slippery slope ...

dbh 

> [mailto:[email-masked]] On Behalf Of Ersue, Mehmet 
> (NSN - DE/Munich)
> Sent: Tuesday, December 16, 2008 4:53 PM
> To: ext Andy Bierman; Martin Bjorklund
> Cc: [email-masked]
> > I want to address real inrability issues, even if

teroperability issues, even if

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Dec 2008 07:29:26 -0800

> THAT looks like a slippery slope ...

It does seem to exhibit less surface friction
than most charter text we are used to seeing ;-)

We do much better when the functionality is
spelled out, and 1 or more solution proposals
exist (netconf-state, partial-locking, with-defaults, etc.)

My concern is simply that re-publishing a protocol
can have significant deployment cost.  There is an errata
publication process for RFCs, and if all we have is
a handful of clarifying sentences, then a new RFC
is of no real help to the industry.  It only
serves the IETF's (non-trivial) self-interest.

Andy

>>> Martin Bjorklund wrote:From [email-masked]  Tue Dec 23 07:29:40 2008
Date: Tue, 23 Dec 2008 07:29:26 -0800
From: Andy Bierman <[email-masked]>
To: David B Harrington <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

> THAT looks like a slippery slope ...

It does seem to exhibit less surface friction
than most charter text we are used to seeing ;-)

We do much better when the functionality is
spelled out, and 1 or more solution proposals
exist (netconf-state, partial-locking, with-defaults, etc.)

My concern is simply that re-publishing a protocol
can have significant deployment cost.  There is an errata
publication process for RFCs, and if all we have is
a handful of clarifying sentences, then a new RFC
is of no real help to the industry.  It only
serves the IETF's (non-trivial) self-interest.

Andy

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 23 Dec 2008 17:29:51 +0100

Andy/David (and others),

our draft WG recharter-text is already inIESG and IAB review.
We did submit it last week remember. 
So... do we really want to start making more changes?
If so, please DO submit proposed alternate/replacement text

Bert
  ----- Original Message ----- 
  From: Andy Bierman 
  To: David B Harrington 
  Cc: [email-masked] 
  Sent: Tuesday, December 23, 2008 4:29 PM
  Subject: Re: [Netconf] Request for charter change

  Andy

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 23 Dec 2008 17:29:51 +0100

Andy/David (and others),

Bert
  ----- Original Message ----- 
  From: Andy Bierman 
  To: David B Harrington 
  Cc: [email-masked] 
  Sent: Tuesday, December 23, 2008 4:29 PM
  Subject: Re: [Netconf] Request for charter change

  Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Dec 2008 08:51:44 -0800

> If so, please DO submit proposed alternate/replacement text

I am not trying to change any text,
but don't kid yourself that the new charter text
in question will be of any use in the future to resolve one
of the those 'in scope or out of scope' decisions.

I think it is good to address interoperability,
instead of just assume everything is going fine.
Juergen's draft is a great first step.  This is the next
logical step.  Real interoperability is the only metric
that matters in the end.

One example: XPath.
Sharon (and others) have commented in the past
that :xpath should be mandatory because everybody
implements it.  Really?  Only 1 of the 3 implementations
in the report claimed to From [email-masked]  Tue Dec 23 08:51:58 2008
Date: Tue, 23 Dec 2008 08:51:44 -0800
From: Andy Bierman <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Request for charter change
Sender: [email-masked]

> If so, please DO submit proposed alternate/replacement text

I am not trying to change any text,
but don't kid yourself that the new charter text
in question will be of any use in the future to resolve one
of the those 'in scope or out of scope' decisions.

I think it is good to address interoperability,
instead of just assume everything is going fine.
Juergen's draft is a great first step.  This is the next
logical step.  Real interoperability is the only metric
that matters in the end.

One example: XPath.
Sharon (and others) have commented in the past
that :xpath should be mandatory because everybody
implements it.  Really?  Only 1 of the 3 implementations
in the report claimimplement it.  Does 'everybody'
implement XPath in an interoperable manner?  How would we know?

It seems odd to me that the RFC is being updated
based on implementation experience, but the WG has
never even requested an implementation report from anybody.

Andy

>     *From:* Andy Bierman <mailto:[email-masked]>
>     *To:* David B Harrington <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Tuesday, December 23, 2008 4:29 PM
>     *Subject:* Re: [Netconf] Request for charter change
> 
>      >> From: [email-masked] <mailto:[email-masked]>
>      >> Cc: [email-masked] <mailto:[email-masked]>
>      >>>> Andy Bierman <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >> [email-masked] <mailto:[email-masked]>
>ed to implement it.  Does 'everybody'
implement XPath in an interoperable manner?  How would we know?

It seems odd to me that the RFC is being updated
based on implementation experience, but the WG has
never even requested an implementation report from anybody.

Andy

>     *From:* Andy Bierman <mailto:[email-masked]>
>     *To:* David B Harrington <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Tuesday, December 23, 2008 4:29 PM
>     *Subject:* Re: [Netconf] Request for charter change
> 
>      >> From: [email-masked] <mailto:[email-masked]>
>      >> Cc: [email-masked] <mailto:[email-masked]>
>      >>>> Andy Bierman <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

 
>     [email-masked] <mailto:[email-masked]>