Subject: [netmod] js review of draft-ietf-netmod-arch-03.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Mar 2010 17:02:34 +0100

Hi,

I have read draft-ietf-netmod-arch-03.txt and I believe the document
needs more work and is not yet ready to go to the IESG.

My main concern is that the document looks like a collection of ideas
related to NETCONF/NETMOD without a clear storyline. Some parts read
like a highlevel summary of NETCONF/YANG (which is however somewhat
incomplete in the discussion of NETCONF/YANG cool features) while
other parts read like advise implementors, data modelers or any future
NETCONF/NETMOD extensions. The section titled "An Architecture for
NETMOD" essentially talks about the benefit of discovering data models
via the capability exchange. It seems the WG needs to find out what
this document's contribution and focus should be.

More detailed comments:

a] Section 1 is not needed since the document does not use RFC 2119
   language. And if it would, I 'd prefer to have this RFC 2119
   language note at the end of the section "Introduction".

b] p5: probably an explanation should be given what "CLI world" means

c] p6,p8,p9,p10: In the examples, I think we should avoid names that
   look like IETF official names, resorting to reserved example names
   and IP addresses.

d] The NETCONF summary is very short, leaving out aspects where
   NETCONF really shines, e.g. the support of different transaction
   models. Now, this might be on purpose - depending on what the focus
   of this document is going to be.

e] Should the document also refer to other NETCONF features such as
   support for notifications? Right now, the document only talks about
   RFC 4741. If the purpose is to provide an introduction, we might
   have to introduce _all_ the pieces that are part of the NETCONF /
   NETMOD technology.

f] p8: The data model should use appropriate uint8/uint16 types - the
   type uint does not really exist in YANG. Also, ospf-types might be
   more appropriate than network-types.

g] There are a number of missing references where the text either says
   [ref] or it says something like [DSDL] that does not appear in the
   reference list.

h] p12: what is "the provider"? Should it be "network operators"?

i] p21: s/that provide explicitely/that explicitely/

j] The security considerations look like a cut 'n paste error.

/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: Andy Bierman <[email-masked]>
Date: Mon, 01 Mar 2010 15:04:21 -0800

> this document's contribution and focus should be.

I agree with your concerns, but I have a specific concern
about the 'transformations' discussed in section 3:

   If the device doesn't implement such a standard or no such standard
   exists, the application may use a transformation that is particular
   to that device's vendor, product model, hardware, or software.
   Depending on the application, this transformation may be provided by
   the application vendor, the device vendor, a third-party, or the
   provider.

   For a popular application, the device vendor may wish to provide this
   transformation to increase market acceptance of their devices.  For
   popular devices, the application may provide this transformation as a
   means of making the application useful in the maximum number of
   provider networks.  For problem domains where the mapping from the
   application to the device is not straight-forward or requires
   tailoring to the specific provider or environment, the provider may
   wish to control this transformation.  Additionally, other parties may
   make such transformations available via open source.

I don't think this document needs to talk about server implementation
details, and refer to undefined transformations that the application
developer may be able to use.

How the server magically produces correct <rpc-reply>
and <notification> outputs is not really an architecture issue.
If the server developer want to support module X, object X1,
and wants to do it by 'plugging in' the code for module Y, object Y1,
that is up to the server vendor.

> /js

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 2 Mar 2010 02:18:55 -0500

>developer may be able to use.

This section tries to illustrate how YANG and NETCONF are able to
help the development of new standards while handling devices that
do not support those standards.  IMHO this is an important feature,
but I will happily remove it if that is the WG concensus.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 2 Mar 2010 02:29:10 -0500

Juergen Schoenwaelder writes:
>It seems the WG needs to find out what

I concur.  Should the focus be closed until only the current WG
documents (YANG, YIN, DSDL) are discussed?  Should it discuss how
YANG fits into the device, or the application?  Or the problem
domain being addressed?  Is it an overview?

There have been many objections to content (and removals), so I
guess I'm confused about where this document fits and what it is
allowed to say.

Please advise.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Mar 2010 09:44:46 +0100

> guess I'm confused about where this document fits and what it is

Right now, the document contains fragments of the following:

1) Overview of NETCONF and YANG, highlighting special features,
   explaining how they can be used in practice

   Likely makes a lot of sense sense, but then I happen to know that
   there is an IEEE Communications Magazine paper in the printing
   pipeline that does try to address this. But yes, I am aware that
   not everybody has access to the IEEE library and surely there is no
   IETF concensus on this paper - so it might be still worthwhile to
   produce a similar RFC.

2) Advise to NETCONF and YANG implementors (servers and apps)

   Might make sense, but might also take time to get agreement on and
   I am not sure how many implementors are going to actively
   contribute to this.
   
3) Advise to YANG data model writers

   Might make sense, but I am not sure how much advise we really
   have. The down to earth part is going to be part of the usage
   document <draft-ietf-netmod-yang-usage-03.txt>.

4) Advise to the evolution of NETCONF and YANG

   I guess this is really going to be difficult to find agreement
   on.

None of these things I really consider an architecture. ;-) Anyway,
the WG needs to figure out (a) what the WG really wants and (b) what
the resources are to write the document the WG wants. There is also
the option to simply drop the ball on this document.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Mar 2010 11:59:07 +0100

It looks like we have lost the premises of this document, and what we
had in mind when we started it.

When NETMOD was chartered there were a lot of discussions why we need
it, what are the alternatives, and how it fits in the landscape of
NETCONF, other ways of writing data models, mappings and translations.
The best we could come before the charter was approved was a napkin
diagram in the good tradition of the IETF which I remember that Mehmet
photographed. It may be interesting to produce that picture for future
historians, but this is not the goal of this discussion. We thought at
that point in time that we need to write a document that describes how
NETMOD interconnects with other components of the NETMOD family of
protocols and possible other network management framework components. 

FWIW the text we put in the WG charter is: 

1. An architecture document explaining the relationship
between YANG and its inputs and outputs. (informational)

I still think that we need this document. If we do not explain well to
ourselves and to the rest of the IETF what we are doing and how it fits
in the broader NM and IETF landscape the YANG effort has less chances of
success.  I do not think that the current version covers well this
scope, maybe only #1 in Juergen's list to some extent, but the rest may
be useful but it is not in scope. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, March 02, 2010 10:45 AM
> To: Phil Shafer
> Cc: [email-masked]
> Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.txt
> 
> > >It seems the WG needs to find out what this document's 
> contribution 
> > >and focus should be.
> > 
> > documents (YANG, YIN, DSDL) are discussed?  Should it 
> discuss how YANG 
> > fits into the device, or the application?  Or the problem 
> domain being 
> > There have been many objections to content (and removals), 
> so I guess 
> > I'm confused about where this document fits and what it is 
> allowed to 
> > say.
> > 
> > Please advise.
> 
> None of these things I really consider an architecture. ;-) 
> Anyway, the WG needs to figure out (a) what the WG really 
> wants and (b) what the resources are to write the document 
> the WG wants. There is also the option to simply drop the 
> ball on this document.
> 
> /js
> 
> -- 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Mar 2010 12:19:45 +0100

> between YANG and its inputs and outputs. (informational)

This sentence is close to a joke. Here is the answer to it:

  YANG is a language for writing NETCONF data models. YANG tools
  process data models written in the YANG language as input and
  produce other representations, translations, code stubs,
  documentation etc. as output.

Is this the document we are after? Could be a one page document plus N
pages of boilerplate. ;-)
 
> be useful but it is not in scope. 

Now you talk about how NETCONF/YANG fits into the rest of the IETF,
which is IMHO very different from "explaining the relationship between
YANG and its inputs and outputs". Explaining how NETCONF/YANG fits
into the IETF's collection of protocols might make sense, but it seems
the charter text does not really point to this. I believe the WG needs
to find the answer what the document should cover. So let me add your
proposal to the list:

5) Overview how NETCONF/YANG fits into the collection of IETF (network
   management) protocols

Any other proposals?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Mar 2010 12:34:16 +0100

See in-line. 

Regards,

Dan

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, March 02, 2010 1:20 PM
> To: Romascanu, Dan (Dan)
> Cc: Phil Shafer; [email-masked]
> between YANG 
> > and its inputs and outputs. (informational)
> 
> Is this the document we are after? Could be a one page 
> document plus N pages of boilerplate. ;-)

This is why I wrote FWIW :-) In the IETF we are not famous with charter
wordsmithing and it may be that the text in the charter is not W too
much, and this is why I am trying to get back to the origins of the
work. The process of having this WG approved was not easy, the IESG, IAB
and participants from other areas in the IETF asked questions and some
of these questions may be back now that the WG output approaches the
IETF Last Call and IESG reviews. 

> > ourselves and to the rest of the IETF what we are doing and how it 
> > fits in the broader NM and IETF landscape the YANG effort has less 
> > chances of success.  I do not think that the current version covers 
> > well this scope, maybe only #1 in Juergen's list to some 
> extent, but 
> > the rest may be useful but it is not in scope.
> 
> Now you talk about how NETCONF/YANG fits into the rest of the 
> IETF, which is IMHO very different from "explaining the 
> relationship between YANG and its inputs and outputs". 
> Explaining how NETCONF/YANG fits into the IETF's collection 
> of protocols might make sense, but it seems the charter text 
> does not really point to this. 

It is not only relations with the IETF collection of protocols, but also
about relations with other modes to express data models that can be used
by NETCONF, translation and mapping between different DMLs. 

> I believe the WG needs to find 
> the answer what the document should cover. So let me add your 
> proposal to the list:
> 

Thank you for adding my proposal to the list. My opinion is that only
part of 1 is within the scope of an architecture document, while 2, 3,
and 4 are out of scope (but may be useful items for future work to be
chartered).

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Mar 2010 13:03:43 +0100

> by NETCONF, translation and mapping between different DMLs. 

YANG -> XSD   		exists, not specified, because DSDL was more sexy
YANG -> DSDL (RNG)	exists
YANG -> SMIv2		does not make sense
YANG -> YIN		exists

XSD -> YANG		nope, full XSD does not make sense and XSD
                        without extensions won't cover what is needed
DSDL -> YANG		nope, full DSDL does not make sense and DSDL
                        without extensions won't cover what is needed
SMIv2 -> YANG		expired ID, could be worked out, not chartered
YIN -> YANG	        exists

What else do you think needs to be discussed? Do we (have to) care
about languages like CIM, GDMO, ... not invented by the IETF? Do we
have to include other ad-hoc IETF protocol specific languages,
e.g. the templates used for defining IPFIX information models, the
somewhat historic SPPI language for COPS-PR? EPP seems to use some
form of commented XSD - I would have to check if they allow any XSD or
some subset.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 02 Mar 2010 13:13:53 +0100

> 5) Overview how NETCONF/YANG fits into the collection of IETF (network

6) Overview of how NETCONF/YANG fits into the XML landscape, explaining
in particular its relationship to the existing schema and data modelling
languages.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Mar 2010 13:37:04 +0100

This looks quite complete. I think that the focus should be on languages
or ways to express XML data models that can work with NETCONF. We need
to deal with what is out of the XML realm only to the extent that it
helps to understand how the existing installed base of MB modules can be
used. This is why I think that talking about SMIv2 -> YANG is still
useful. If there are other DMLs that need to be mapped / translated into
YANG we can deal with them later. 

Dan

> Sent: Tuesday, March 02, 2010 2:04 PM
> To: Romascanu, Dan (Dan)
> > It is not only relations with the IETF collection of protocols, but 
> > also about relations with other modes to express data 
> models that can 
> > be used by NETCONF, translation and mapping between different DMLs.
> 
> What else do you think needs to be discussed? Do we (have to) 
> care about languages like CIM, GDMO, ... not invented by the 
> IETF? Do we have to include other ad-hoc IETF protocol 
> specific languages, e.g. the templates used for defining 
> IPFIX information models, the somewhat historic SPPI language 
> for COPS-PR? EPP seems to use some form of commented XSD - I 
> would have to check if they allow any XSD or some subset.
> 
> /js
> 
> --

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Mar 2010 13:38:31 +0100

> [mailto:[email-masked]] On Behalf Of Ladislav Lhotka

> 
> 6) Overview of how NETCONF/YANG fits into the XML landscape, 
> explaining in particular its relationship to the existing 
> schema and data modelling languages.
> 
> Lada
> 
> 

Indeed. 

Dan

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 2 Mar 2010 14:27:38 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, March 02, 2010 3:19 AM
...
> Any other proposals?
...

Explain how it helps (or does not) address issues raised in the IAB
workshop oh-so-long-ago.  Ones that come to mind at the moment 
include:

- providing a systematic way of relating vendor-specific features
  to standardized models
- supporting automation of the generation of vendor-specific
  configuration data from generic configuration requirements
- supporting configuration of multi-system abstractions, like a
  trunk, where successful configuration requires delivery of
  configuration data to multiple devices
- versioning of configuration data
- separation of access control configuration data from
  configuration configuration data
- pre-provisioning support
- human-friendly configuration data representations
- support for federation of administrative domains

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 02 Mar 2010 14:39:06 -0800

> - support for federation of administrative domains

This is all very nice, but we went through all this
when the arch document was chartered.

IMO, Phil has done a great job with a very vague charter.
The WG never chimed in with any input about clarifying the
"inputs and outputs of YANG" charter scope.  Each review
cycle, there have been lots of comments about what is in
scope for this document.  Nobody is really sure.

Maybe if we called it an Overview document instead of the
over-loaded 'Architecture' term?  The document is Informational,
so no future standards track documents are going to be
constrained by any normative reference to this document.

I propose we take the path that gets this document
done the fastest, without expanding the scope at
the last minute.  (I don't know what that is though :-)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Mar 2010 08:05:17 +0100

> IMO, Phil has done a great job with a very vague charter.

Nobody is criticizing Phil. It is the charter text which is not clear
and we likely all remember how this document got on the charter.

> scope for this document.  Nobody is really sure.

Exactly. This is why I am trying to get us working towards a WG
decision what this document's scope is going to be. The current list
of things to choose from:

6) Overview of how NETCONF/YANG fits into the XML landscape,
   explaining in particular its relationship to the existing
   schema and data modelling languages

7) Explain how it helps (or does not) address issues raised in
   the IAB workshop oh-so-long-ago

> constrained by any normative reference to this document.

So you seem to vote for option 1) of the above.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Mar 2010 11:27:27 +0100

> over-loaded 
> > 'Architecture' term?  The document is Informational, so no future 
> > standards track documents are going to be constrained by 
> any normative 
> > reference to this document.
> 

This is fine and probably useful, but it does not meet the scope of the
work as defined (not in the best words) in the charter. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Mar 2010 04:35:15 -0800

> So you seem to vote for option 1) of the above.

I don't want to change the charter.
I never agreed with it in the first place.

One could address many 'architectural' aspects of YANG:

 1) Why doesn't YANG need to address NETCONF protocol capabilities?
 2) Why doesn't YANG need any conformance mechanisms like SMIv2?
    (I have found the lack of a read-only conformance mechanism
     to be a serious lack of functionality.)
 3) Why doesn't SMIv2 have an Architecture document, explaining
    the ins and outs of the language?  Why does SNMP have a
    protocol architecture document instead?
 4) YANG allows every vendor to add its own language statements.
    Why isn't the IETF concerned that there will be so many
    different variants of YANG in use that interoperability
    will be harmed?  What level of readability and multi-vendor
    interoperability does the IETF even expect from YANG?
 5) YANG is theoretically applicable to other protocols beyond
    NETCONF, yet the language is not written in a way that explains
    or even suggests that it could apply to another protocol.
    How does this claim in the charter impact future revisions of
    the YANG language?  Will there ever be an attempt to make this
    1 language apply to more than 1 protocol?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Mar 2010 10:24:07 -0800

> but I will happily remove it if that is the WG concensus.

I understand your motivation.
I happen to think the traditional IETF approach
of defining the exact database contents that every
server must support is just one tool in the box.
It has never really worked in the IETF so insisting
it is the only path to operational interoperability
seems doomed to failure.

In addition, there has always been an expectation
that vendor data models will co-exist with standard
data models.  Usually the vendor data model is done first,
and the standard followed years later.  This process
works OK for monitoring, but it is seriously flawed
for configuration.

These 'data model transformations' may end up being
a viable standard mechanism for client applications to use.
But now, they are just an undefined vendor-specific thing.

I think this document should explain the role of
vendor data models, vendor extensions to standard data models,
and vendor deviations to standard data models.
The text about transformations may be fine in a section like that.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 5 Mar 2010 09:58:54 -0500

>work as defined (not in the best words) in the charter. 

My feeling is that the following need to be addressed in the arch draft:

(a) why we did it // the problem domain
(b) what we did // how the moving parts work
(c) how you use it // what a yang-based solution looks like
(d) real world issues // minor bits that need to be written down

The official scope might only cover (b) but without saying what we
aimed for (a) and how to use it (c), we can't call it "architecture".

The (d) section may not be pretty but this material needs to be
written down somewhere.  Jeurgen's text on data is an example of (d).

Large sections of the original (a) and (c) were removed, and this
has made the document less readable.  I would like to attempt to
rebuild these section with less objectionable content instead of
simply removing them.  IMHO they are needed.

Unless there are objections, I'll make another attempt.

Thanks,
 Phil

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Mar 2010 11:25:59 +0100

> From: Phil Shafer [mailto:[email-masked]] 
> Sent: Friday, March 05, 2010 4:59 PM
> To: Romascanu, Dan (Dan)
> Cc: Juergen Schoenwaelder; Andy Bierman; [email-masked]
> The official scope might only cover (b) but without saying 
> what we aimed for (a) and how to use it (c), we can't call it 
> "architecture".
> 
> The (d) section may not be pretty but this material needs to 
> be written down somewhere.  Jeurgen's text on data is an 
> example of (d).
> 
> Large sections of the original (a) and (c) were removed, and 
> this has made the document less readable.  I would like to 
> attempt to rebuild these section with less objectionable 
> content instead of simply removing them.  IMHO they are needed.
> 

Ok with me, as long as the goals we had in mind when we started this
work are covered. 

Dan

---

From: Phil Shafer <[email-masked]>
Date: Mon, 8 Mar 2010 18:00:53 -0500

>Filename:        draft-ietf-netmod-arch
>Revision:        04
>Title:           An NETCONF- and NETMOD-based Architecture for Network Management
>Creation_date:   2010-03-08
>WG ID:           netmod
>Number_of_pages: 27

Please read and give feedback.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Mar 2010 16:14:27 -0800

> Please read and give feedback.

I really like it!

That assumes I am allowed to just read the document without
any preconceived ideas about what an ARCH spec contains.

The empty security considerations section is probably
not going to make the IESG happy. (We'll see)

Andy