Subject: Re: [netmod] Arch draft comments

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 28 Apr 2009 13:33:57 +0200

Here are my comments and questions. I apologize for the delay. 

Regards,

Dan

1. In the Abstract you say '   NETCONF and YANG are pieces of an
ambitious plan to improve network management.'. Please keep your hidden
agenda in the dark :-) Neither NETCONF nor YANG were chartered with such
ambitious plans. I suggest to reformulate the phrasing keeping the scope
to what was approved by consensus in the IETF (configuration management,
notifications capabilities). You can certainly mention that the
architecture is extensible and may cover more management functionality
in the future, but better keep it less declarative at this phase. The
title should also rather be 'A NETCONF and NETMOD based Architecture for
Network Management'. 

2. 'This document describes how NETCONF and YANG help build network
   management applications that meet the needs of network services
   providers.'

I would rather say 'network operators' than 'network service providers'.
There is nothing in NETCONF and YANG that prevents them being used in
enterprise networks or home networks. 

3. I prefer to refer to NETMOD rather than YANG in the general sections.
The document is about how NETCONF and NETMOD architecture works, with
NETMOD including YANG, but not only YANG. From this perspective naming
YIN a 'related technology' is misguiding. YIN is an integral part of the
NETMOD architecture. 

4. Editorial nit - Make YANG / yang capitalization consistent

5. I had a hard time in understanding what section 6 tries to tell. A
device that includes an unacceptable deviations behavior may behave as
unexpectedly you can get, and I cannot see how an application can
'expect' and deal with such implementations. Also the usage of the term
'node' in this section is misguiding - do you mean routers? But then
people may use some NETCONF and NETMOD for hosts, or servers, or other
network devices. 

6. Section 7 does not seem to say anything useful

7. I am not sure that the Security Considerations section should be
null. We are defining an architecture and not only a data modeling
language in this document. Is there nothing to say for example about
access-rights on the different elements of the management domain and how
they are being kept or mapped in the different translations? 

8. Should we say nothing about basic types in YANG and their
extensibility?

9. Should we say nothing about the backwards (lack of) compatibility to
SMI and the translation tools? 

> -----Original Message-----
> From: Phil Shafer [mailto:[email-masked]] 
> Sent: Monday, April 27, 2009 10:31 PM
> To: Romascanu, Dan (Dan)
> Subject: Arch draft comments
> 
> Dan,
>   In SF, you said you had some comments on the arch draft.
> Could I please get them from you asap?
> 
> Thanks,
>  Phil
>