Subject: [netmod] FW: architecture document scope

From: "David B Harrington" <[email-masked]>
Date: Mon, 15 Sep 2008 17:08:26 -0400

[speaking as co-chair] 

The IETF debated the charter and the purpose of the WG, and agreed to
a charter that called for an architecture that describes the inputs
and outputs of YANG. The architecture document should not make any
claims that YANG is **THE** language for Netconf. That is not what the
IETF agreed to when this WG was chartered, and it was obvious that
IETF consensus was that some people wanted to use the existing
XML-based tools to do their modeling.

As co-chair, I am trying to make sure we keep the architecture
document limited to the scope we are authorized to address by the
charter.

[speaking as individual contributor]

I do not believe this document should be a "Netconf architecture"
document - that should be the responsibility of the Netconf WG. Many
of the items in Andy's list of things to include should not be
included here, since they are about netconf, not netmod. 

I certainly have no objection to explaining that YANG is
designed to work within a Netconf architecture. But it should NOT be
our job to define what a Netconf architecture is. Since Netconf WG has
not published an architecture document, this makes our job harder, but
I think it is pretty simple to say that Netconf can carry any valid
XML, and that YANG defines a schema language for specifying an XML
format that can be used as Netconf content. The important part is that
YANG is designed to be a user-friendly schema langauge, and then to
describe the purpose of the other documents we will produce from YANG.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Tuesday, September 09, 2008 6:11 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [netmod] architecture document scope
> 
> Juergen,
> 
> I would not spend too much time looking strictly at the words in the
> charter - especially when we deal with architecture.  
> 
> I do understand - I think - what we had in mind when we put the YANG
> architecture document in the charter, and this was related to
> clarification of specific issues that were discussed during the
> formation of the WG about how the flow of models in different 
> languages
> will work and what is in-between. I agree with your observation that
> part of the output is tools dependent - but this is part of the
> clarification. 
> 
> What would a 'big picture' architecture for NETCONF include in your
> opinion? What NETCONF architectural concepts are missing to 
> provide for
> the NETMOD architecture? 
> 
> I do not hide that I am somehow concerned that when we would 
> get to the
> NETCONF architecture we would need to refer a broader 
> architecture view
> of the IETF management architecture. From boiling a cup of 
> tea we got to
> boiling a lake and we then get close to boiling the ocean. 
> 
> Dan
> 
> (speaking as a contributor)
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
> > Sent: Tuesday, September 09, 2008 10:13 AM
> > To: [email-masked]
> > Subject: [netmod] architecture document scope
> > 
> > Hi,
> > 
> > I think we need to agree what the purpose and scope of the 
> > architecture document is. The NETMOD charter says:
> > 
> >   1. An architecture document explaining the relationship
> >      between YANG and its inputs and outputs. (informational)
> > 
> > This is rather fuzzy. While the input is clear (data models 
> > written in YANG), the output is less clear since at the end 
> > of the day we want YANG models to be implemented in NETCONF 
> > servers as the output. How you get there is tool dependent.
> > 
> > For me, it would make more sense to have an architecture 
> > document describing the big picture behind NETCONF plus YANG. 
> > Since YANG is a domain specific language for NETCONF, I would 
> > even argue that a YANG architecture has to reference NETCONF 
> > architectural concepts and since we do not have a NETCONF 
> > architecture, we need to address this anyhow.
> > 
> > What is the WGs opinion?
> > 
> > /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/>
> > _______________________________________________
> > netmod mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> 

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Sep 2008 16:22:56 -0700

> document limited to the scope we are authorized to address by the

The phrase "inputs and outputs of YANG" is fairly vague.
There are all kinds of NETCONF-isms throughout
the YANG document.  This is fine with me, since I plan
to use YANG to define NETCONF protocol content.
It's not clear to me what else YANG should be used for,
but I would like to make sure it is useful for that protocol.

The YANG input is a sequence of UTF-8 characters,
probably typed into a file by a human.  The output
are supposedly DSDL files.  This sounds great, wrt/
the IETF view of the problem space, but it doesn't
seem to address the real problem space.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Sep 2008 08:53:35 +0200

> seem to address the real problem space.

Yes. Perhaps we should take the charter literally as DBH suggests and
produce a 1-2 pages document along the paragraph above and be done
with this deliverable quickly.

/js

Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Sep 2008 20:44:54 -0400

> but I would like to make sure it is useful for that protocol.

As I said, YANG is designed to be used within a Netconf environment.
> seem to address the real problem space.

YANG input can also yield YIN output
YANG input can also yield on-the-wire XML
In the future, work might be done to provide translations to other
formats, but those are not part of the charter of the netmod WG
In the future, work might be done to provide translations from other
formats, but those are not part of the charter of the netmod WG

The purpose of the architecture document is to explain what the
different document types are and their use cases:
YANG is meant to be user-friendly
YIN is meant to represent in an XML-tools friendly format.
on-the-wire XML is meant to meet certain requirements for readability
on the sire requested by operators.
DSDL is meant to represent YANG models in DSDL-tools friendly format.

---

From: Phil Shafer <[email-masked]>
Date: Tue, 16 Sep 2008 22:00:54 -0400

>DSDL is meant to represent YANG models in DSDL-tools friendly format. 

Is this missing in the current draft?  Am I going into too much
detail?  I readily admit I have no clue what the target zone is or
if I'm even pointing down range.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Sep 2008 08:21:37 +0200

> YANG input can also yield on-the-wire XML

YANG input can yield *constraints* for on-the-wire XML and integration
into NETCONF PDUs. This is IMO the main role of the DSDL translation.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Sep 2008 06:40:01 -0700

> if I'm even pointing down range.

Apparently the NETMOD architecture is supposed to heavily
depend on the NETCONF architecture, which doesn't exist.

I think what Juergen is suggesting is a very generic NETMOD arch,
which I support as well:

    NETCONF content is defined in 1 or more collections of UTF-8 characters,
    called YANG modules.

    An XML encoding of the YANG language is supported via the
    YANG to YIN mapping specification. This allows tools which
    manipulate XML to be used to process YANG modules.

    Conceptual NETCONF operations and configuration database data structures
    can be associated with the YANG language mechanisms, and is
    supported via the YANG to XML mapping rules within the YANG specification.

    The syntax and constraints for XML documents representing NETCONF
    PDUs containing YANG data structures can be specified with various
    XML modeling languages.  The DSDL standard is supported for this
    purpose, via the YANG to DSDL mapping specification.

Without NETCONF details out of scope,  how much more can you say about
NETMOD?

Andy