On May 15, 2008, at 10:28 PM, 袁智辉 wrote:

How is the state of arts of NETCONF (RFC 4741) protocol?

Is there any Network Management System Deployed which is base on NETCONF?

I've personally been waiting for the data modeling to be standardized. Yes, it's great and wonderful to have a consistent method of talking to network devices, but I also want a standard data model along with it.

Do you think security products (like Firewall, IDS/IPS and Security Operation Centre) can benefit from NETCONF?

I believe any network device can benefit from netconf.

Randy Bush writes: [in response to John Payne <john@sackheads.org>:]

...

I've personally been waiting for the data modeling to be standardized. Yes, it's great and wonderful to have a consistent method of talking to network devices, but I also want a standard data model along with it.

does this not imply that all devices would need to be semantically congruent? if so, is this realistic?

Personally I don't think it is. The way that configuration is structured is something that at least some vendors use to differentiate themselves from each other. (Though other vendors make a point of being compatible with some "industry standard CLI".) So if you think that configurations in NETCONF should be similar to the "native" configuration language, that doesn't bode well for industry-wide standardization of a NETCONF configuration data model. It might still be possible to have a common NETCONF data model, but then that would probably be quite different from the (all) "native" configuration languages; much in the same way as SNMP MIBs are (structurally) different from how information is presented at the CLI. Personally I'm not sure that this would be a very useful outcome, because there would necessarily be a large lag between when features are implemented (with a "native" CLI to configure them of course) and when they can be configured through NETCONF. Maybe the best we can shoot for is this: * A common language to describe parts of NETCONF configuration. The newly chartered IETF NETMOD working group[1] is working on this. Vendors can then describe their specific NETCONF data models using this language, and tool writers can use these descriptions to generate code for applications that want to manipulate device configurations. * Common data models for certain well-understood parts of NETCONF configuration. This could include simple "atomic" things such as how to write an IP address or a prefix in (NETCONF) XML, or configuration of standardized protocols such as OSPF, IPFIX etc. The problem is how well will this support migration from vendor-specific configuration to standardized configuration - which, as I said, is always bound to lag far behind. And even if/when an aspect of a configuration model (let's say for OSPF) is standardized, vendors are bound to extend that model to support not-yet-standardized extensions (e.g. sub-second timers, BFD). This will be another challenge to support. (But there are smart people working on this :-) -- Simon. [1] http://www.ietf.org/html.charters/netmod-charter.html

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, Interesting comment Paul. However, 16e and evdo are a "bit" heavy with infrastructure to support mobility. Before giving that answer, you may want to ask Deepak if he NEEDS mobility.... Chris On 16 May 2008, at 10.23, Paul Wall wrote:

On Thu, May 15, 2008 at 4:21 PM, Deepak Jain <deepak@ai.net> wrote:

...

Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas?

BCP #58,271,432--which basically states "Don't," comes highly recommended.

Instead, investigate your nearest .16e or evdo rev. A reseller. In the case of .16e, most available APN's are built around user and transport/transit abstractions, assuming shared-facilities, virtual providers, etc. The equipment used in both is a far cry from anything 802.11.

p.

_______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog

- --- 李柯睿 Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJILcx7AAoJEGmx2Mt/+Iw/20UIAJjNOQ7JSbE8/iqGbuFZPEVX AvQ/eRPHT6BhLXNSg5WZiL4aQcDeLhkMYwhpJTMkslHg5hveQHN/pUQB9pkMeqCZ jffRbiKDzypaDf8q/Rx1vORO/bnQ4R27AfeKDc75Z07YewdBa9PKZz2EgsjVHQmp FNDq9dVDWAI+scK3BFNge+QNeXatYUf0gP+LnRmNaPu+KZBThjD+Wmd6FWlfmuRa GxvTOrESrbhRxrnF128B5RXa/GBohduiql1jrU0phb6w2a/NJbd+a4yvHANZpBHk fwU3BrZKLixRtOOM3uA4ZPgliTUO/lD4tpW8SEWnvluhRe1tTIrmgf4qjxit5gA= =z83n -----END PGP SIGNATURE-----