Subject: [OPSAWG] review of draft-schoenw-opsawg-copspr-historic-00.txt

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Sep 2009 12:55:22 -0400

Hi,

First, I strongly recomend the draft be made a WG draft.

s/Policy Decision Point (PEP)/Policy Decision Point (PDP)/
s/so called Policy Information Bases/Policy Information Bases/
s/a framework for specifying/a data modeling language for specifying/
s/concensus/consensus/
s/lead/led/
s/the associated YANG data modeling language [YANG]/an associated
XML-based data modeling language [YANG]./

I'm not sure I understand this sentence:
   These new
   protocols are specifically designed to match the needs of network
   operators and all configuration management related efforts in the
   IETF are not centered on NETCONF and YANG.
I agree with the first part of this sentence. 
I agree with the second part of the sentence, but only as written. I
think you have a typo. You probably meant to say "now" rather than
"not". 

I would disagree strongly that "all configuration management related
efforts in the IETF are now centered on NETCONF and YANG." 

There are currently 24 IDs that show up in a search for
"configuration" in the Internet Draft search engine. Only three are
related to netconf and YANG, of which two are about the netconf
protocol itself; only one defines a YANG data model. All three that
mention netconf are OPS area documents. The other 21 do not mention
netconf or YANG, and they discuss non-OPS-area approaches to doing
configuration.

The feedback we have gotten on the operations and management
guidelines document is that the guidelines are very OPS-area-centric
and very router-config-centric. The guidelines document reflects some
of the same OPS-area biases that are reflected in the designs of
netconf and YANG. Other areas in the IETF are seriously looking at
other mechanisms to do configuration.  YANG has not yet been submitted
for approval as a standard. To claim that IETF is focusing on YANG I
think is seriously over-reaching. I think YANG is in serious danger of
being ignored by most areas of the IETF, and by most equipment
vendors. XML is being seriously considered, but most WGs are
generating schemas in XMLSchema, not YANG.

Despite the fact my parent company uses COPS-PR in products, I
strongly agree that COPS-PR should be declared Historic. The COPS-PR
design was overtaken by events - the operator community actively
provided feedback about their needs, the emergence of XML over ASN.1
for on-the-wire encoding, the strong operator dislike of OIDs, the
desire to move away from the SNMP/MIB peek/poke approach, the slow
adoption of secure SNMP, the lack of suppport for SETs, the
convergence of datacom and telecom management, and the emergence of
more IETF standards for services and applications have all rendered
COPS-PR designs somewhat inappropriate. COPS-PR built upon SNMP and
MIBs, when the industry trend was to move away from the SNMP/MIB
approach. We should recognize and dcoument why COPS-PR was not
accepted by operators, and why the IETF decided against continuing
work on COPS-PR and PIBs, and why it is NOT RECOMMENDED.

Netconf and YANG have yet to prove themselves in the marketplace, or
achieve rough consensus throughout the IETF. They are certainly the
center of OPS-area-centric and router-centric device management, but
that is not the only thing the IETF focuses on configuring now.

We should NOT use this reclassification document as a marketing
vehicle for netconf and YANG. 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Sep 2009 23:26:50 +0200

> s/Policy Decision Point (PEP)/Policy Decision Point (PDP)/

fixed

> s/so called Policy Information Bases/Policy Information Bases/

fixed

> s/a framework for specifying/a data modeling language for specifying/

fixed

> s/concensus/consensus/

fixed

> s/lead/led/

fixed

> XML-based data modeling language [YANG]./

I am not sure what "XML-based" means nor do I think this information
is necessary. I prefer:

/an associated data modeling language called YANG [YANG]/
 
> think you have a typo. You probably meant to say "now" rather than

This was a nice typo. ;-)
 
> vehicle for netconf and YANG. 

So what was your proposal? What about this:

        [...] configuration management related efforts in the IETF
        operations and management area are now centered on NETCONF and
        YANG.

Just to be clear: I have zero interest to discuss the history and from
reading other RFCs retiring documents I conclude that this also does
not seem necessary. I also do not want to write a marketing document
but I think it is fair to point readers to alternatives. This is done
in other RFCs retiring documents as well.

/js

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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Sep 2009 18:48:47 -0400

> /an associated data modeling language called YANG [YANG]/

Your paragraph is about the IAB Workshop documented in RFC3535, and
apparently is there
to explain why Netconf and YANG are the (OPS) preferred alternatives:
   An IAB Network Management Workshop held in 2002 [RFC3535] lead to
the
   creation of the Network Configuration Protocol (NETCONF) [RFC4741]
   and the associated YANG data modeling language [YANG].  These new
   protocols are specifically designed to match the needs of network
   operators and all configuration management related efforts in the
   IETF are now centered on NETCONF and YANG.

RFC3535 reports:
   4.  The workshop recommends, with strong consensus from both
protocol
       developers and operators, that the IETF focus resources on the
       standardization of configuration management mechanisms.

   5.  The workshop recommends, with strong consensus from the
operators
       and rough consensus from the protocol developers, that the
       IETF/IRTF should spend resources on the development and
       standardization of XML-based device configuration and
management
       technologies (such as common XML configuration schemas,
exchange
       protocols and so on).

Your paragraph tries to explain why Netconf and YANG are preferred
over COPS-PR, but I think more needs to be said about which operators'
needs are met, and how these alternatives meet the requirements
described in RFC3535. There are people who think COPS-PR is useful,
and we should explain why Netconf/YANG should be used rather than
COPS-PR. 

I suggest:

   An IAB Network Management Workshop held in 2002 [RFC3535] led to
the
   creation of the Network Configuration Protocol (NETCONF) [RFC4741]
   and an associated XML-based data modeling language [YANG].  These
new
   protocols are specifically designed to meet the recommendations of
the
   workshop to address the needs of network operators:
   - Netconf standardizes configuration management mechanisms, and
uses an 
   Extensible Markup Language (XML)-based data encoding for the
configuration 
   data as well as the protocol messages.
   - YANG focuses on a limited problem space -  expressing NETCONF
data models, 
   not arbitrary XML documents or arbitrary data models.  The data
models
   described by YANG are designed to be easily operated upon by
NETCONF
   operations. YANG modules can be translated into an XML format
called YANG
   Independent Notation (YIN), allowing applications using
   XML parsers and XSLT scripts to operate on the models. 

(I do think we should have a bit of discussion of the technical
reasons why COPS-PR was considered NOT RECOMMENDED - the global lock,
non-deterministic clients, etc.)

>         operations and management area are now centered on NETCONF
and

How about 
[...] device configuration management efforts in the IETF Operations
and Management Area are now centered on NETCONF and YANG. Other areas 
of the IETF are considering the NETCONF/YANG solution plus other
possible 
alternatives for configuration of their technologies.

dbh

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 30 Sep 2009 13:05:02 +0200

I agree and I support the direction, but I am not sure about the level
of detail that this document should enter in describing NETCONF and
YANG. Mentioning that COPS=PR is considered overtaken by events,
mentioning that NETCONF and YANG were developped to specifically meet
the operators requirements documented by RFC 3535, and also saying that
other areas may use NETCONF / YANG or other specific means to implement
configuration management, but COPS-PR is seldom or never mentioned as an
alternative seems to me sufficient. As David points it looks more
important to talk about the reasons COPS-PR was considered inadequate,
than showing in too much details how its replacements meet the needs. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Wednesday, September 30, 2009 12:49 AM
> To: 'Juergen Schoenwaelder'
> Cc: [email-masked]
> Subject: Re: [OPSAWG] review of 
> draft-schoenw-opsawg-copspr-historic-00.txt
> 
> 
>  
> 
> Your paragraph is about the IAB Workshop documented in 
> RFC3535, and apparently is there to explain why Netconf and 
> YANG are the (OPS) preferred alternatives:
>    An IAB Network Management Workshop held in 2002 [RFC3535] 
> lead to the
>    4.  The workshop recommends, with strong consensus from 
> both protocol
>    5.  The workshop recommends, with strong consensus from 
> the operators
>        technologies (such as common XML configuration 
> schemas, exchange
>        protocols and so on).
> 
> Your paragraph tries to explain why Netconf and YANG are 
> preferred over COPS-PR, but I think more needs to be said 
> about which operators'
> needs are met, and how these alternatives meet the 
> requirements described in RFC3535. There are people who think 
> COPS-PR is useful, and we should explain why Netconf/YANG 
> should be used rather than COPS-PR. 
> 
> I suggest:
> 
>    An IAB Network Management Workshop held in 2002 [RFC3535] 
> led to the
>    and an associated XML-based data modeling language [YANG]. 
>  These new
>    protocols are specifically designed to meet the 
> recommendations of the
>    - Netconf standardizes configuration management 
> mechanisms, and uses an 
>    Extensible Markup Language (XML)-based data encoding for 
> the configuration 
>    - YANG focuses on a limited problem space -  expressing 
> NETCONF data models, 
>    not arbitrary XML documents or arbitrary data models.  The 
> data models
>    described by YANG are designed to be easily operated upon 
> by NETCONF
>    operations. YANG modules can be translated into an XML 
> format called YANG
> (I do think we should have a bit of discussion of the 
> technical reasons why COPS-PR was considered NOT RECOMMENDED 
> - the global lock, non-deterministic clients, etc.)
> 
> [...] device configuration management efforts in the IETF 
> Operations and Management Area are now centered on NETCONF 
> and YANG. Other areas of the IETF are considering the 
> NETCONF/YANG solution plus other possible alternatives for 
> configuration of their technologies.
> 
> dbh
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Sep 2009 13:48:27 +0200

> alternatives for configuration of their technologies.

Thanks for your input. I have taken up some suggestions, others I have
left out other that I think are not relevant for declaring COPS-PR and
friends historic or where the added terminology remains unclear or
open to interpretation. I am posting a new revision so we can
synchronize.

/js