Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

From: Balazs Lengyel <[email-masked]>
Date: Tue, 22 Jul 2008 13:58:09 +0200

Hi Marc, Sharon, Martin,

I reviewed the draft NETCONF Monitoring Schema.
Please find my comments below.

General comments)

- The comments/descriptions in the YANG and the XSD should be the same.

Abstract)
Remove the word dynamically, IMHO it does not mean anything

Definition of terms)
Remove Element, not used
Operation refers to the notifications, change it!
Mention YANG

I was wondering if schema or model or model fragment is the correct term ?

2.1.1. capabilities
 From RFC4741: "The device uses capabilities to announce the set From [email-masked]  Tue Jul 22 04:57:53 2008
Date: Tue, 22 Jul 2008 13:58:09 +0200
From: Balazs Lengyel <[email-masked]>
To: Mark Scott <[email-masked]>, Sharon Chisholm <[email-masked]>,
	Martin Bjorklund <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: [Netconf]  Review of draft-ietf-netconf-monitoring-02.txt
Sender: [email-masked]

This is a multi-part message in MIME format.

Hi Marc, Sharon, Martin,

I reviewed the draft NETCONF Monitoring Schema.
Please find my comments below.

General comments)

- The comments/descriptions in the YANG and the XSD should be the same.

Abstract)
Remove the word dynamically, IMHO it does not mean anything

Definition of terms)
Remove Element, not used
Operation refers to the notifications, change it!
Mention YANG

I was wondering if schema or model or model fragment is the correct term ?

2.1.1. capabilities
 From RFC4741: "The device uses capabilities to announce the set of datof data 
models that the device implements."
This to me means that the device MUST advertise all it's models as 
capabilities as well. So the models will be included both in the 
capabilities and the schemas branch. Please indicate this.

Remove minimally. I think all capabilities MUST be advertised already in 
the HELLO message; or are you thinking of new capabilities/models that 
appear during a session?

2.1.2. configurations
The list of nodes is the authoritative information on a partial lock. 
Please place it before the select leaf. The select is only provided for 
completeness, to show the original intent of the locking entity and is 
only informational.

2.1.6 Statistics
- Maybe clarify that we only provide Netconf statistics.
- On page 38 for inSessions you have a short expression identifying how 
the different counters relate to each other. More such expressions would 
be VERY good. E.g. good RPCs = inRPCs - inXMLParseErrors - inBadRpcs - 
inNotSupportedRpcs
- Add something like: a Netconf message can be either Hello messages or 
Rpcs.

Would it be interesting to count whether sessions end with close, kill, 
or loss of transport? The last could indicate problems, while too many 
kills could indicate hacking or locking problems

5.1 Netconf Monitoring Schema
I only briefly checked this part.
- Page 18) It is strange that we have separately ConfigurationDatastore 
and ConfigurationDatastoreType and both are TYPEs. A different name 
should be chosen for one of them.
- I think ncEvent should also be imported
- a few things don't have a type e.g. lockedNodes, select
- Page 24) Why is ConfigurationDatastoreType not reused from RFC4741?

- Will it be possible to add new values to SchemaFormat, TransportType 
and ProtocolType? It is sure that we will have new things here. (We 
(Ericsson) already have e.g. LDAP)

5.2 int:host schema
This should be a separate draft as many other will need it. Is there 
today no XML schema for such basic stuff? Can we refer to 
draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? 
Anyone who cares about XSD should start pushing that draft!
- I think there are some differences between how YANG and this draft 
defines domainName. They should be aligned!

Appendix A YANG

- ConfigurationDatastoreType should be defined in a separate 
netconfRFC4741 module.
- SchemaFormat, TransportType and ProtocolType must be choice, as 
enumerations are not extensible and it is definite that we will have new 
values for these.
- Is the corect name RNG or DSDL
- The Netconf container shall be config true. Only containers below it 
should be config false. It is quite possible that we will later 
(possibly in another draft/rfc) add stuff under netconf that is 
configurable or that someone wants to extend it with configurable 
settings e.g. access control, max-number of paralel sessions.
- /netconf/configurations/configuration/locks/lockedBySession should be 
a keyref
- lockedNodes should come before select as lockedNodes is the 
authoritative information
- do we need top level containers like schemas? We could have the list 
schema directly under /netconf
- /netconf/subscriptions/subscription/sessionId should be a keyref

X.  IANA Considerations
Do we register any XML namespaces? I guess so.
Shall we also start the YANG registry?

regards Balazs

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 22 Jul 2008 12:21:31 -0400

hi
 
Thanks for your comments.  Replies inline.
 
Sharon

________________________________

From: Balazs Lengyel [mailto:[email-masked]] 
Sent: Tuesday, July 22, 2008 7:58 AM
To: Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin
Bjorklund
Cc: netconf mailing list
Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

Hi Marc, Sharon, Martin, 

 <clip> 

2.1.1. capabilities
>From RFC4741: "The device uses capabilities to announce the set of data

 <sharon> 
Experience hFrom [email-masked]  Tue Jul 22 09:21:18 2008
Content-class: urn:content-classes:message
Date: Tue, 22 Jul 2008 12:21:31 -0400
From: "Sharon Chisholm" <[email-masked]>
To: "Balazs Lengyel" <[email-masked]>,
	"Mark Scott" <[email-masked]>, "Martin Bjorklund" <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Sender: [email-masked]

hi
 
Thanks for your comments.  Replies inline.
 
Sharon

________________________________

From: Balazs Lengyel [mailto:[email-masked]] 
Sent: Tuesday, July 22, 2008 7:58 AM
To: Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin
Bjorklund
Cc: netconf mailing list
Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

Hi Marc, Sharon, Martin, 

 <clip> 

2.1.1. capabilities
>From RFC4741: "The device uses capabilities to announce the set of data

 <sharon> 
Experias shown that was a not the best way to get data model
definitions.  I don't think we need to repeat that advise here. We may
want to remove it in an update to RFC4741.
</sharon>  

5.2 int:host schema

<sharon>

We looked at that and either it didn't meet our needs or there was a
namespace issue, either way, we couldn't use it. In general, if we can
get better data types by not deriving them from legacy definitions then
we should not be afraid to do that. I agree though that this should be a
separate document..

</sharon>

Appendix A YANG

 <clip a long list of issues>

<sharon>  
 We probably should only have a  pointer to the yang definition stored
elsewhere. We can't have any dependencies on  the netmod work if we plan
on completing on schedule. Anything we include in this ID, even in
non-normative form, can't help but be out of date since netmod  won't be
done when we publish.

</sharon> 

regards Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jul 2008 09:38:41 -0700

Sharon Chisholm wrote:
> ------------------------------------------------------------------------
> *From:* Balazs Lengyel [mailto:[email-masked]]
> *Sent:* Tuesday, July 22, 2008 7:58 AM
> *To:* Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin Bjorklund
> *Cc:* netconf mailing list
> *Subject:* [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
> 
> Hi Marc, Sharon, Martin,
> 
> Experience has shown that was a not the best way to get data model 

I think it is useful to send the module capabilities in the <hello>.
The very first the manager needs to do is get these module caps,
so it can make sure compatible versions of all the relevant modules
are loaded.  Unless the manager is using a proprietary mechanism
(e.g., identifying packages or profiles, not individual modules),
then it will take the same amount of bandwidth and memory for
the <get> as the <hello>.

I support an additional <get> for module-caps, because the
alternative is to rely on a proprietary API to access the
<hello> message.

Andy

> ------------------------------------------------------------------------
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jul 2008 09:38:41 -0700

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 22 Jul 2008 19:12:44 +0200

Hello,

Andy Bierman wrote:
>>
>> 2.1.1. capabilities
>>  From RFC4741: "The device uses capabilities to announce the set of 
>> data models that the device implements."
> so it can make sure compatiFrom [email-masked]  Tue Jul 22 09:42:15 2008
Date: Tue, 22 Jul 2008 19:12:44 +0200
From: Balazs Lengyel <[email-masked]>
To: Andy Bierman <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Sender: [email-masked]

Hello,

Andy Bierman wrote:
>>
>> 2.1.1. capabilities
>>  From RFC4741: "The device uses capabilities to announce the set of 
>> data models that the device implements."
> so it can make sure compatible veble versions of all the relevant modules
Andy, according to RFC4741 do you consider it mandatory to advertise all data models?
- yes
- no
- yes, but as this is a mistake, we should forget it?

Balazs

rsions of all the relevant modules
> the <get> as the <hello>.
Andy, according to RFC4741 do you consider it mandatory to advertise all data models?
- yes
- no
- yes, but as this is a mistake, we should forget it?

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 22 Jul 2008 19:29:45 +0200

> we should not be afraid to do that. I agree though that this should be a 
{BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so it can not be legacy. Also 
Bob Natale indicated to me that he intends to go on working on it, so join forces.
> non-normative form, can't help but be out of date since netmod  won't be 
{BALAZS}: I disagree. I believe making YANG informative deals with the timing. I have already 
seen the first emails stating that they mostly look at YANG not the XSD.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 22 Jul 2008 19:29:45 +0200

Balazs

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 22 Jul 2008 12:58:13 -0400

> elsewhere. We can't have any dependencies on  the netmod work if we 
> plan on completing on schedule. Anything we include in this ID, even 
> in non-normative form, can't help but be out of date since netmod  
> won't be done when we publish.
> 
> </sharon>
> 
{BALAZS}: I disagree. I believe making YANG informative deals with the
timing. I have already seen the first emails stating that they mostly
look at YANG not the XSD.

This isn't a beauty contest question. We have a normative language for
defining content at the moment and we have work in progress. As I
stated, we need to minimize the dependencies in the draft on work in
progress. If some people find it useful to also having netmod stuff
available, I think it makes more sense to do it outside the draft, where
it will be easier to keep up to date and the standards evolve.

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 22 Jul 2008 12:58:13 -0400

Sharon

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jul 2008 10:25:12 -0700

Balazs Lengyel wrote:
>>> definitions.  I don't think we need to repeat that advise here. We 
>>> may want to remove it in an update to RFC4741.
>>> </sharon> 
>>

No, it is not mandatory.
Only the 'base' capability is mandatory, indicating
support for the RFC 4741 version of NETCONF.

I think it is easier (at many levels) to define a standard data
model and standard <get-schema> RPC method, than it is to add
additional standard features to the <hello> message.
(E.g., I don't want to deal with access control for <hello> PDUs).

I think the NETCONF spec should remain silent on adding
proprietary <capability> elements, and the schema discovery
draft should be the only standard mechanism defined for this purpose.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jul 2008 10:25:12 -0700

No, it is not mandatory.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 22 Jul 2008 13:38:36 -0400

"Sharon Chisholm" writes:
"Balazs Lengyel" writes:
>>2.1.1. capabilities
>>From RFC4741: "The device uses capabilities to announce the set of data models
>>that the device implements."
>>This to me means that the device MUST advertise all it's models as capabilities
>>as well. So the models will be included both in the capabilities and the
>>schemas branch. Please indicate this. 
>

This is a bit shocking.  Can you give some details about this
experience?  I've had no problems with it.  Was this discussed
on the mailing list earlier?  Can you give a pointer please?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 22 Jul 2008 13:38:36 -0400

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Jul 2008 22:51:44 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> 
> 
> Sharon Chisholm wrote:
> > 5.2 int:host schema
> > This should be a separate draft as many other will need it. Is
> > there today no XML schema for such basic stuff? Can we refer to
> > We looked at that and either it didn't meet our needs or there was
> > a namespace issue, either way, we couldn't use it. In general, if we
> > can get better data types by not deriving them from legacy
> > definitions then we should not be afraid to do that. I agree though
> > that this should be a separate document..
> > </sharon>
> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so
> it can not be legacy. Also Bob Natale indicated to me that he
> intends to go on working on it, so join forces. 

If I understand the intention of
draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is supposed to
provide a direct XSD version of SMI data types.  No nice-to-have types
will be defined by this spec.

For this particular type (inet:host), the best SMIv2 type we can use
is InetAddress from rfc 4001, but we can do better in XML (see e.g.
inet-types.yang :).

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Jul 2008 22:51:44 +0200 (CEST)

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 22 Jul 2008 22:55:00 +0200

Should we ask Bob to change his aim? Both Netconf monitoring and DSDL will need the XSD types.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 22 Jul 2008 22:55:00 +0200

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 22 Jul 2008 17:42:46 -0400

Hi Balazs,

Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd
exactly right -- I really don't see any prospect of a change in the
purpose of that document (now at -02 and I'm hoping very close to being
ready for WGLC).

Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd will likely
be of the same nature -- as faithful as possible of a direct
representations of the major TCs we have defined for SNMP, using the
same set of requirements (suitably adjusted where necessary) defined
for the base SMI datatypes.

Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow for more
creativity in terms of representing MIB structure in XSD, although I
believe our plan (led by Dave Harrington)From [email-masked]  Tue Jul 22 14:42:47 2008
Content-class: urn:content-classes:message
Date: Tue, 22 Jul 2008 17:42:46 -0400
From: "Natale, Bob" <[email-masked]>
To: "Balazs Lengyel" <[email-masked]>,
	"Martin Bjorklund" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Sender: [email-masked]

Hi Balazs,

Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd
exactly right -- I really don't see any prospect of a change in the
purpose of that document (now at -02 and I'm hoping very close to being
ready for WGLC).

Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd will likely
be of the same nature -- as faithful as possible of a direct
representations of the major TCs we have defined for SNMP, using the
same set of requirements (suitably adjusted where necessary) defined
for the base SMI datatypes.

Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow for more
creativity in terms of representing MIB structure in XSD, although I
believe our plan (led by Dave Harrington) is avoid unnecessary
incompatibilities with libsmi.

(I've used tentative titles on the last two documents wrt OPSAWG
sponsorship, anticipating that the pattern there will follow from the
base datatypes document.)

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Balazs Lengyel
Sent: Tuesday, July 22, 2008 4:55 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

Should we ask Bob to change his aim? Both Netconf monitoring and DSDL
will need the XSD types.
Balazs

 is avoid unnecessary
incompatibilities with libsmi.

(I've used tentative titles on the last two documents wrt OPSAWG
sponsorship, anticipating that the pattern there will follow from the
base datatypes document.)

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Balazs Lengyel
Sent: Tuesday, July 22, 2008 4:55 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

Should we ask Bob to change his aim? Both Netconf monitoring and DSDL
will need the XSD types.
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 23 Jul 2008 10:39:20 +0200

Hello Bob, Dan,
Sorry to spoil your plan, but I see it as a bad thing that we will end up with two slightly 
incompatible set of XSD types. One coming directly from SMI/SNMP and another related to the 
Netmod/DSDL/Netconf Monitoring work. (Could we have 3 sets by separating the Monitoring and the 
DSDL data types ? It would be fun :-)

Dan whats your opinion about the issue?

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 23 Jul 2008 10:39:20 +0200

Hello Bob, Dan,

Balazs

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jul 2008 11:08:52 +0200

Balazs,

I do not have a strong opinion (yet). I need to hear more arguments one
side and the other of the dispute between the direct translation of
existing SMI types and the 'we can do better in XML' version. 

Dan

> Sent: Wednesday, July 23, 2008 11:39 AM
> To: Natale, Bob; Romascanu, Dan (Dan)
> Cc: Martin Bjorklund; [email-masked]
> Sorry to spoil your plan, but I see it as a bad thing that we 
> will end up with two slightly incompatible set of XSD types. 
> One coming directly from SMI/SNMP and another related to the 
> Netmod/DSDL/Netconf Monitoring work. (Could we have 3 sets by 
> separating the Monitoring and the DSDL data types ? It would 
> be fun :-)
> 
> > purpose of that document (now at -02 and I'm hoping very close to 
> > being ready for WGLC).
> >

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jul 2008 11:08:52 +0200

Balazs,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2008 11:17:59 +0200

> existing SMI types and the 'we can do better in XML' version. 

Dan,

we will need both. Direct translation is essential to have in order to
use SMIv2 definitions in an XML world. However, we need to also look
ahead and should not unnecessarily constrain NETCONF configuration
models by sticking to limitations imposed by the SMIv2. I don't see a
problem in general here - just a challenge to find the right balance
and to document properly which say YANG types remain consistent with
an SMIv2 equivalent and which ones do not.

The more scary part (which I mentioned already several weeks ago) is
that we have one group working on SMIv2->XSD translations and another
group working on SMIv2->YANG->XSD translations. Despite this being
perhaps a waste of resources, if the results of both translation
chains are not identical, I believe we are really screwed.

/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/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2008 11:17:59 +0200

Dan,

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jul 2008 11:30:10 +0200

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, July 23, 2008 12:18 PM
> To: Romascanu, Dan (Dan)
> Cc: Balazs Lengyel; Natale, Bob; [email-masked]
> > I do not have a strong opinion (yet). I need to hear more arguments 
> > one side and the other of the dispute between the direct 
> translation 
> > of existing SMI types and the 'we can do better in XML' version.
> 
> Dan,
> 
> we will need both. Direct translation is essential to have in 
> order to use SMIv2 definitions in an XML world. However, we 
> need to also look ahead and should not unnecessarily 
> constrain NETCONF configuration models by sticking to 
> limitations imposed by the SMIv2. I don't see a problem in 
> general here - just a challenge to find the right balance and 
> to document properly which say YANG types remain consistent 
> with an SMIv2 equivalent and which ones do not.
> 
> The more scary part (which I mentioned already several weeks 
> ago) is that we have one group working on SMIv2->XSD 
> translations and another group working on SMIv2->YANG->XSD 
> translations. Despite this being perhaps a waste of 
> resources, if the results of both translation chains are not 
> identical, I believe we are really screwed.
> 
> /js
> 

What I am missing probably due to the lack of understanding of the
details on my side (hopefully temporary) is whether achieving identical
translation is doable, and if yes at what cost. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jul 2008 11:30:10 +0200

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2008 11:45:58 +0200

> translation is doable, and if yes at what cost. 

IETF cost means delay. If we do SMIv2->YANG->XSD, we get SMIv2->XSD
for free except that doing both in parallel might be faster (but if
you want to have the result consistent, this argument becomes void).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2008 11:45:58 +0200

/js

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 23 Jul 2008 07:42:39 -0400

Hi Dan,

There is a set of potential XML-based management applications -- and a
user community that needs them -- that requires maximum compatibility
and interoperability with legacy/existing SNMP management applications
and managed resources.  In that context, these applications -- and
their developers and their users -- do not need "anything better" or
anything "extra" ... they need as close to the original as possible ...
and sooner rather than later.  Hence, the "XSDMI" effort -- which
continues to strive to avoid gratuitous incompatibilities with the rest
of the IETF O&M world, but does claim to have valid requirements for
the stated purpose.

Rushed,
BobN

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2008 5:09 AM
To: Balazs Lengyel; Natale, Bob
Cc: Martin Bjorklund; [email-masked]
Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

Balazs,

Dan

> >>>> a namespace issue, either way, we couldn't use it. In general,
if
> > we

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 23 Jul 2008 07:42:39 -0400

Hi Dan,

Rushed,
BobN

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2008 5:09 AM
To: Balazs Lengyel; Natale, Bob
Cc: Martin Bjorklund; [email-masked]
Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

Balazs,

Dan

if

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2008 14:45:02 +0200

On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote:
 
> anytFrom [email-masked]  Wed Jul 23 05:44:29 2008
Date: Wed, 23 Jul 2008 14:45:02 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Natale, Bob" <[email-masked]>
Mail-Followup-To: "Natale, Bob" <[email-masked]>,
	"Romascanu, Dan (Dan)" <[email-masked]>,
	Balazs Lengyel <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote:
 
> anything "hing "extra" ... they need as close to the original as possible ...
> and sooner rather than later.

Let them speak up here...

> Hence, the "XSDMI" effort -- which continues to strive to avoid
> gratuitous incompatibilities with the rest of the IETF O&M world,
> but does claim to have valid requirements for the stated purpose.

I have not seen anybody doing "gratuitous incompatibilities" lately.

As you know, there are tools like libsmi that do already SMIv2 to XSD
and SMIv2 to YANG conversions and there are already tools to do YANG
to XSD conversions. Being involved with some of the tools, I like to
see the result produced to be identical since I believe this gives us
a long term benefit.

/js

extra" ... they need as close to the original as possible ...
> and sooner rather than later.

Let them speak up here...

> Hence, the "XSDMI" effort -- which continues to strive to avoid
> gratuitous incompatibilities with the rest of the IETF O&M world,
> but does claim to have valid requirements for the stated purpose.

I have not seen anybody doing "gratuitous incompatibilities" lately.

As you know, there are tools like libsmi that do already SMIv2 to XSD
and SMIv2 to YANG conversions and there are already tools to do YANG
to XSD conversions. Being involved with some of the tools, I like to
see the result produced to be identical since I believe this gives us
a long term benefit.

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 23 Jul 2008 09:44:17 -0400

Hi

My view on this topic is that we need high-quality data types. In some
cases this is possible while supporting simple translations from SNMP
MIBs, but in other cases it will not. In the cases where optimizing for
the translation results in sub-optimal data types definitions for use in
NETCONF, we need go with the high-quality types. (And no, I don't have a
concrete definition of 'high-quality').

In this case, it may be possible to align on a single definition for
these items. I believe that Bob's is missing a namespace declaration, so
that need to be addressed. I think then the only definition of potential
interest from that set was IpAddress, but as defined it I don't think it
supports ipV6, or if it does, it doesn't do it with ":" separators. I
think the inet:host schema in the monitoring draft has a more complete
solution for IP addresses. If we decide we want to merge this work, then
it needs to be publiFrom [email-masked]  Wed Jul 23 06:44:25 2008
Content-class: urn:content-classes:message
Date: Wed, 23 Jul 2008 09:44:17 -0400
From: "Sharon Chisholm" <[email-masked]>
To: <[email-masked]>, "Natale, Bob" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Sender: [email-masked]

Hi

My view on this topic is that we need high-quality data types. In some
cases this is possible while supporting simple translations from SNMP
MIBs, but in other cases it will not. In the cases where optimizing for
the translation results in sub-optimal data types definitions for use in
NETCONF, we need go with the high-quality types. (And no, I don't have a
concrete definition of 'high-quality').

In this case, it may be possible to align on a single definition for
these items. I believe that Bob's is missing a namespace declaration, so
that need to be addressed. I think then the only definition of potential
interest from that set was IpAddress, but as defined it I don't think it
supports ipV6, or if it does, it doesn't do it with ":" separators. I
think the inet:host schema in the monitoring draft has a more complete
solution for IP addresses. If we decide we want to merge this work, then
it needs to be published ished in a specification that isn't SNMP specific.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, July 23, 2008 8:45 AM
To: Natale, Bob
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

> gratuitous incompatibilities with the rest of the IETF O&M world, but 
> does claim to have valid requirements for the stated purpose.

As you know, there are tools like libsmi that do already SMIv2 to XSD
and SMIv2 to YANG conversions and there are already tools to do YANG to
XSD conversions. Being involved with some of the tools, I like to see
the result produced to be identical since I believe this gives us a long
term benefit.

/js

n a specification that isn't SNMP specific.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, July 23, 2008 8:45 AM
To: Natale, Bob
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

> gratuitous incompatibilities with the rest of the IETF O&M world, but 
> does claim to have valid requirements for the stated purpose.

As you know, there are tools like libsmi that do already SMIv2 to XSD
and SMIv2 to YANG conversions and there are already tools to do YANG to
XSD conversions. Being involved with some of the tools, I like to see
the result produced to be identical since I believe this gives us a long
term benefit.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2008 16:49:32 +0200

On Wed, Jul 23, 2008 at 09:44:17AM -0400, Sharon Chisholm wrote:
 
> interest from that set was IpAddress, but as definedFrom [email-masked]  Wed Jul 23 07:48:58 2008
Date: Wed, 23 Jul 2008 16:49:32 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Sharon Chisholm <[email-masked]>
Mail-Followup-To: Sharon Chisholm <[email-masked]>,
	"Natale, Bob" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Jul 23, 2008 at 09:44:17AM -0400, Sharon Chisholm wrote:
 
> interest from that set was IpAddress, but as defined it I  it I don't think it
> it needs to be published in a specification that isn't SNMP specific.

So how is inet:host different from what you get out of translating the
YANG inet:host definition into XSD? The fact that these things are
different is what IMHO a good standardization body needs to avoid.
And the approach to constantly align N different definitions does not
scale well and is asking for trouble if you ask me.

/js

don't think it
> it needs to be published in a specification that isn't SNMP specific.

So how is inet:host different from what you get out of translating the
YANG inet:host definition into XSD? The fact that these things are
different is what IMHO a good standardization body needs to avoid.
And the approach to constantly align N different definitions does not
scale well and is asking for trouble if you ask me.

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 23 Jul 2008 11:18:20 -0400

Hi

Aside from the format of the name, it like looks ipAddress maps
reasonably well.  We also have a definition for domainName which I don't
think is covered in the yang data types. 

Sharon

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Wednesday, July 23, 2008 10:50 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Natale, Bob; [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

On Wed, Jul 23, 2008 at 09:44:17AM -0400, Sharon Chisholm wrote:
 
> these items. I believe that Bob's is missing a namespace declaration, 
> so that need to be addressed. I think then the only definition of 
> potential interest from that set was IpAddress, but as defined it I 
> don't think it supports ipV6, or ifFrom [email-masked]  Wed Jul 23 08:17:52 2008
Content-class: urn:content-classes:message
Date: Wed, 23 Jul 2008 11:18:20 -0400
From: "Sharon Chisholm" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Sender: [email-masked]

Hi

Aside from the format of the name, it like looks ipAddress maps
reasonably well.  We also have a definition for domainName which I don't
think is covered in the yang data types. 

Sharon

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Wednesday, July 23, 2008 10:50 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Natale, Bob; [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

On Wed, Jul 23, 2008 at 09:44:17AM -0400, Sharon Chisholm wrote:
 
> these items. I believe that Bob's is missing a namespace declaration, 
> so that need to be addressed. I think then the only definition of 
> potential interest from that set was IpAddress, but as defined it I 
> don't think it supports ipV6, it does, it doesn't do it with ":"

> separators. I think the inet:host schema in the monitoring draft has a

> more complete solution for IP addresses. If we decide we want to merge

> this work, then it needs to be published in a specification that isn't
SNMP specific.

/js

 or if it does, it doesn't do it with ":"

> separators. I think the inet:host schema in the monitoring draft has a

> more complete solution for IP addresses. If we decide we want to merge

> this work, then it needs to be published in a specification that isn't
SNMP specific.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2008 17:55:24 +0200

On Wed, Jul 23, 2008 at 11:18:20AM -0400, Sharon Chisholm wrote:
 
> think is coFrom [email-masked]  Wed Jul 23 08:54:50 2008
Date: Wed, 23 Jul 2008 17:55:24 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Sharon Chisholm <[email-masked]>, Dan Romascanu <[email-masked]>
Mail-Followup-To: Sharon Chisholm <[email-masked]>,
	Dan Romascanu <[email-masked]>,
	"Natale, Bob" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Reply-To: [email-masked]
Sender: [email-masked]

> think is covered in the yang data types. 

Well, you seem to ignore all the fancy details such as patterns. Are
they really the same? And yes, I think there is something for domain
names in inet-types.yang as well:

      typedef host {
          type union {
              type inet:ip-address;
              type inet:domain-name;
          }
          description
             "The host type represents either an IP address
              or a DNS domain name.";
      }

If it is already too difficult for authors to find out these rather
obvious differences, how can we believe we will ever reach a
consistent result?

Dan, I believe this simple example is proof enough that the issue is
out there and we should take advantage of the face-to-face meeting
next week to find a way to address this issue.

/js

vered in the yang data types. 

Well, you seem to ignore all the fancy details such as patterns. Are
they really the same? And yes, I think there is something for domain
names in inet-types.yang as well:

      typedef host {
          type union {
              type inet:ip-address;
              type inet:domain-name;
          }
          description
             "The host type represents either an IP address
              or a DNS domain name.";
      }

If it is already too difficult for authors to find out these rather
obvious differences, how can we believe we will ever reach a
consistent result?

Dan, I believe this simple example is proof enough that the issue is
out there and we should take advantage of the face-to-face meeting
next week to find a way to address this issue.

/js

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 23 Jul 2008 13:11:30 -0400

Hi Sharon,

Thanks for the observations:

1. I will add the namespace definition in an -03 update imminently --
oversight in -02.

2. The SMIv2 (RFC2578) definition of IpAddress is:
IpAddress ::=
    [APPLICATION 0]
        IMPLICIT OCTET STRING (SIZE (4))

That is all -- with the associated value restrictions -- XSDMI intends
to represent in the base SMI datatypes set.

I don't have a view on the need for high-quality data types (sure
sounds like a good thing though) -- I'm just concerned in this context
with XSD to validate the direct translation of SMI-compliant SNMP data
into XML.

Cheers,
BobN

-----Original Message-----
From: Sharon Chisholm [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2008 9:44 AM
To: [email-masked]; Natale, Bob
Cc: [email-masked]
Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

Hi

My view on this topic is that we need high-quality data types. In some
cases this is possible while supporting simple translations from SNMP
MIBs, but in other cases it will not. In the cases where optimizing for
the translation results in sub-optimal data types definitions for use
in
NETCONF, we need go with the high-quality types. (And no, I don't have
a
concrete definition of 'high-quality').

In this case, it may be possible to align on a single definition for
these items. I believe that Bob's is missing a namespace declaration,
so
that need to be addressed. I think then the only definition of
potential
interest from that set was IpAddress, but as defined it I don't think
it
supports ipV6, or if it does, it doesn't do it with ":" separators. I
think the inet:host schema in the monitoring draft has a more complete
solution for IP addresses. If we decide we want to merge this work,
then
it needs to be published in a specification that isn't SNMP specific.

Sharon 

-----Original Message-----

As you know, there are tools like libsmi that do already SMIv2 to XSD
and SMIv2 to YANG conversions and there are already tools to do YANG to
XSD conversions. Being involved with some of the tools, I like to see
the result produced to be identical since I believe this gives us a
long
term benefit.

/js

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 23 Jul 2008 13:11:30 -0400

Hi Sharon,

Cheers,
BobN

-----Original Message-----
From: Sharon Chisholm [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2008 9:44 AM
To: [email-masked]; Natale, Bob
Cc: [email-masked]
Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

Hi

Sharon 

-----Original Message-----

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jul 2008 19:21:01 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Natale, Bob

>         IMPLICIT OCTET STRING (SIZE (4))

FWIW - this is not any longer sufficient. 

See RFC4001 

   Several standards-track MIB modules use the IpAddress SMIv2 base
   type.  This limits the applicability of these MIB modules to IP
   Version 4 (IPv4), as the IpAddress SMIv2 base type can only contain
   4-byte IPv4 addresses.  The IpAddress SMIv2 base type has become
   problematic with the introduction of IP Version 6 (IPv6) addresses
   [RFC3513].

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jul 2008 19:21:01 +0200

See RFC4001 

Dan

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 23 Jul 2008 16:12:09 -0400

Gee, I think we should shoot for low-quality data types. ;-)

Seriously, what defines a "better" datatype?

I will use the BridgeId definition in YANG-LIB as an example.
BridgeId in RFC4188 is defined to match the binary representation
pulled from 802.1D spanning tree messages. IETF and IEEE agreed on
this format.
bridgeid in YANG-LIB is defined to use a textual formatted string with
a colon separator instead. (and it uses a "reference" of RFC4188,
which seems odd)

Which is better?
Which is more "high-quality"?
Which is better for directly comparing to the binary values passed in
the spanning tree BPDU?
Which one has chosen to diverge so now we have two different XSD
datatypes?

XSDMI is designed explicitly to be faithful to the original SMIv2
definitions.
XSDMI is designed to explicitly avoid "improving" the SMIv2 datatypes.

XSDMI and YANG-LIB have different purposes, and different formats are
"better" for different purposes. It is perfectly legal to have
different XML schemas to represent the same thing for different (or
even the same) purpose. 

SMIv2 datatypes are IETF standards, and XSDMI is trying to remain true
to the standard datatypes developed by IETF community consensus. If
you want to change those standards because you think you can do
better, then go open a WG to change all the existing MIBs to match
your "better" definitions. Oh, and for BridgeId don't forget to open
projects in IEEE to change their MIB modules, and maybe their BPDU
formats, as well. 

XSDMI wants to use the existing SMIv2 definitions as faithfully as
possible because we think those are "high-quality" definitons already
agreed to by the IETF community, and using the same definition/format
is likely to enhance interoperability.

dbh

> Sent: Wednesday, July 23, 2008 1:12 PM
> To: Sharon Chisholm; [email-masked]
> Cc: [email-masked]
> > There is a set of potential XML-based management applications --
and

> > anything "extra" ... they need as close to the original as
possible
> ...

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 23 Jul 2008 16:12:09 -0400

Which is better?

dbh

and

possible

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jul 2008 16:33:56 -0400

Hi,

That is probably why SMIv2 includes the comment line:

-- (this is a tagged type for historical reasons)
IpAddress ::=
    [APPLICATION 0]
        IMPLICIT OCTET STRING (SIZE (4))

There are still MIB modules that have IpAddress type objects in them,
and some applications (such as manager) night want to be able to
(faithfully) represent that value in an XML format.
XSDMI does not recommend using this type; it merely provides a
translation of an existing IETF standard datatype.

dbh

> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Wednesday, July 23, 2008 1:21 PM
> To: Natale, Bob; Sharon Chisholm;
[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jul 2008 16:33:56 -0400

Hi,

dbh

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jul 2008 22:36:27 +0200

So I assume that there are or will be in XSDMI corresponding
translations of the RFC4001 TCs, right?  

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, July 23, 2008 11:34 PM
> To: Romascanu, Dan (Dan); 'Natale, Bob'; 'Sharon Chisholm'; 
> -- (this is a tagged type for historical reasons) IpAddress ::=
>     [APPLICATION 0]
> There are still MIB modules that have IpAddress type objects 
> in them, and some applications (such as manager) night want 
> to be able to
> XSDMI does not recommend using this type; it merely provides 
> a translation of an existing IETF standard datatype.
> 
> dbh
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jul 2008 22:36:27 +0200

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jul 2008 09:45:09 +0200

> translations of the RFC4001 TCs, right?  

There are tools out there translate everything you can define in SMIv2
to XSD by means of relatively simple translation rules. There is IMHO
no point in hand translating selected TCs. Instead, you have to
specify the translation rules and everything falls out from that.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 35From [email-masked]  Thu Jul 24 00:44:34 2008
Date: Thu, 24 Jul 2008 09:45:09 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Mail-Followup-To: "Romascanu, Dan (Dan)" <[email-masked]>,
	David Harrington <[email-masked]>,
	"Natale, Bob" <[email-masked]>,
	Sharon Chisholm <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Reply-To: [email-masked]
Sender: [email-masked]

> translations of the RFC4001 TCs, right?  

There are tools out there translate everything you can define in SMIv2
to XSD by means of relatively simple translation rules. There is IMHO
no point in hand translating selected TCs. Instead, you have to
specify the translation rules and everything falls out from that.

/js

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

     Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 24 Jul 2008 09:53:45 +0200

> Sent: Thursday, July 24, 2008 10:45 AM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Natale, Bob; Sharon Chisholm; [email-masked]
> There are tools out there translate everything you can define 
> in SMIv2 to XSD by means of relatively simple translation 
> rules. There is IMHO no point in hand translating selected 
> TCs. Instead, you have to specify the translation rules and 
> everything falls out from that.
> 
> /js
> 

So, in your opinion, the specification of the translation rules shFrom [email-masked]  Thu Jul 24 00:53:16 2008
Content-class: urn:content-classes:message
Date: Thu, 24 Jul 2008 09:53:45 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Sender: [email-masked]

> Sent: Thursday, July 24, 2008 10:45 AM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Natale, Bob; Sharon Chisholm; [email-masked]
> There are tools out there translate everything you can define 
> in SMIv2 to XSD by means of relatively simple translation 
> rules. There is IMHO no point in hand translating selected 
> TCs. Instead, you have to specify the translation rules and 
> everything falls out from that.
> 
> /js
> 

So, in your opinion, the specification of the translation rules should
be the sole (principal?) scope of standardization in this area? Or is
there a need to optimize the output to get that 'better quality' level
for some of the commonly used structures? 

Dan

ould
be the sole (principal?) scope of standardization in this area? Or is
there a need to optimize the output to get that 'better quality' level
for some of the commonly used structures? 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jul 2008 09:55:49 +0200

> I will use the BridgeId definition in YANG-LIB as an example.

There is not YANG-LIB - but I know what you mean. ;-)

> a colon separator instead. (and it uses a "reference" of RFC4188,

So what do you think is the appropriate "faithful to SMIv2"
representation of BridgeId in XML?

> Which one has chosen to diverge so now we have two different XSD

Can you explain to me why <draft-ietf-opsawg-smi-datatypes-in-xsd-01>
represents an IP address in dotted quad notation while it is on the
wire (in SNMP and IP) just a four octet field? Can you explain to me
why the same document represents OIDs in dotted number notation while
they are BER encoded 7bit binary number sequences in SNMP? Can you
answer the above questions for each of these examples?

> definitions.  XSDMI is designed to explicitly avoid "improving" the
> SMIv2 datatypes.
>

In the light of the current XSDMI definition, I think you are slighly
exaggerating. Or are you going to ask the IETF to redo IPv4 because of
the new XSDMI definition of an IPv4 address?

> is likely to enhance interoperability.

I guess we need a definition of "faithfully" now in addition to a
definition of "better". I suggest to do a bar bof next week to clarify
all these terms. ;-)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jul 2008 09:55:49 +0200

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jul 2008 10:39:59 +0200

> for some of the commonly used structures?

There are two work items we have to distinguish:

a] The first work item is reuse of existing SMIv2 definitions in XML
   based protocols and for this we need translation rules. Whether the
   rules contain very specific rules to deal with some specific but
   frequently occuring constructs is subject to the group defining the
   rules. At the end, however, everything has to be automatic since
   nobody is going to hand translate stuff that is out there.

b] The second work item are data types for new definitions. In some
   cases, translation rules will not produce reasonable results (a
   good example is the InetAddress family of TCs that try to work
   around the lack of proper unions in the SMIv2). While any new
   definitions should align to existing definitions as much as
   possible, there will be cases where this requires discussion. For
   me, the BridgeID is a good example of this kind of discussion and
   there is in my view no way to avoid these discussions for cases
   where the binary representation implied by the SMIv2 does not match
   the more textual XSD approach or where the SMIv2 representation is
   specific to SNMP and SMIv2 limitations which do not exist in other
   XML based protocols such as NETCONF.

My understanding was that XSDMI is addressing a] while NETMOD will
work on b] to produce reusable constructs for new configuration data
models.

Excursion to the real world: I am familiar with a particular
implementation that has translation rules to directly translate
SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF
efforts to specify how to translate YANG->XSD. So given FOO-MIB, I can
do already today:

1)	FOO-MIB -> FOO-MIB.xsd
2)	FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd

And the result is not the same. Assuming that NETCONF will be used to
provide access to SMIv2 instrumentation, I believe we are in trouble.

Back from the real world to the IETF: There is a work item in the
OPSAWG to do 1). Approach 2) is covered partially in the NETMOD WG
(the YANG->XSD mapping). So from your perspective, you can say there
is no problem as of now. ;-)

In practice, there is already running code for all of this and if we
do not find a way to make the translation rules consistent in time
(whatever that means in the IETF ;-), I believe we will see that
people use differnet translation rules and we are going to pay the
bill later on.

There are different solutions possible to deal with this issue. Some
solutions I quickly can come up with (but this is not meant to be a
complete list):

a) Translation of SMIv2 to YANG is simply forbitten, only the direct
   translation to XSD is allowed.

b) Both translations are developed at the same time and we ensure that
   things are coordinated and that at the end that the outcome of the
   two translation paths is consistent.

c) Both translation roads are engineered in parallel and who completes
   first wins and the other one has to adapt to the winner, regardless
   how painful this will be.

d) Settle on a single translation approach but make sure that everyone
   interested in the other approach is made aware to follow it closely
   to ensure that problems are avoided (this is essentially b) without
   managed coordination).

e) Declare that this problem is not worth solving since XML namespaces
   will take care of the differences and application writers can deal
   with it.

f) Postpone the problem.

All I am suggesting is to discuss this issue openly and fairly on
technical grounds with the goal to avoid incompatible XSD translations
of SMIv2 modules.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jul 2008 10:39:59 +0200

f) Postpone the problem.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 24 Jul 2008 11:04:55 +0200

> Sent: Thursday, July 24, 2008 11:40 AM
> To: Romascanu, Dan (Dan)
> My understanding was that XSDMI is addressing a] while NETMOD 
> will work on b] to produce reusable constructs for new 
> configuration data models.
> 
> efforts to specify how to translate YANG->XSD. So given 
> FOO-MIB, I can do already today:
> 
> And the result is not the same. Assuming that NETCONF will be 
> used to provide access to SMIv2 instrumentation, I believe we 
> are in trouble.
> 
> Back from the real world to the IETF: There is a work item in 
> the OPSAWG to do 1). Approach 2) is covered partially in the 
> NETMOD WG (the YANG->XSD mapping). So from your perspective, 
> you can say there is no problem as of now. ;-)
> 
> In practice, there is already running code for all of this 
> and if we do not find a way to make the translation rules 
> consistent in time (whatever that means in the IETF ;-), I 
> believe we will see that people use differnet translation 
> rules and we are going to pay the bill later on.
> 
> There are different solutions possible to deal with this 
> issue. Some solutions I quickly can come up with (but this is 
> not meant to be a complete list):
> 
> All I am suggesting is to discuss this issue openly and 
> fairly on technical grounds with the goal to avoid 
> incompatible XSD translations of SMIv2 modules.
> 
> /js
> 

The discussion certainly needs to happen and is happening. 

My understanding is that the approach taken by the XSDMI is assuming e)
and is not necessarily targeting NETCONF (or only NETCONF). This is the
approved goal in OPSAWG.  Do you feel that the namespace differentiation
not enough? After all if the approach that strictly reuses what was
defined in SMIv2 will not find an immediate applications, and the
NETCONF approach will have clear advantages, no harm will be made to the
NETCONF DM path. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 24 Jul 2008 11:04:55 +0200

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jul 2008 12:02:38 +0200

On Thu, Jul 24, 2008 at 11:04:55AM +0200, Romascanu, Dan (Dan) wrote:
 
> not enough? After all if the From [email-masked]  Thu Jul 24 03:02:01 2008
Date: Thu, 24 Jul 2008 12:02:38 +0200

> NETCONF approach will have clear advantages, no harm will be made to the

If there is general agreement that e) is the way to go, then I will
shut up and then implementors can enjoy the freedom to choose whatever
XSD translation they like most.

/js

approach that strictly reuses what was
> NETCONF approach will have clear advantages, no harm will be made to the

If there is general agreement that e) is the way to go, then I will
shut up and then implementors can enjoy the freedom to choose whatever
XSD translation they like most.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 24 Jul 2008 13:10:41 +0200

> Sent: Thursday, July 24, 2008 1:03 PM
> To: Romascanu, Dan (Dan)
> > My understanding is that the approach taken by the XSDMI is 
> assuming 
> > e) and is not necessarily targeting NETCONF (or only 
> NETCONF). This is 
> > the approved goal in OPSAWG.  Do you feel that the namespace 
> > differentiation not enough? After all if the approach that strictly 
> > reuses what was defined in SMIv2 will not find an immediate 
> > applications, and the NETCONF approach will have clear 
> advantages, no 
> > harm will be made to the NETCONF DM path.
> 
> If there is general agreement that e) is the way to go, then 
> I will shut up and then implementors can enjoy the freedom to 
> choose whatever XSD translation they like most.
> 
> /js
> 

Just to make clear, I am not expressing an opinion, and certainly  I am
not giving any 'AD advice' or something similar at this point. I am
asking clarification questions, the discussion is open and I suggest
that we use email and face to face discussions for folks who will be
present in Dublin to try to a sense of consensus (if there is one). 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 24 Jul 2008 13:10:41 +0200

Dan

---

From: David Partain <[email-masked]>
Date: Thu, 24 Jul 2008 13:35:24 +0200

Hi,

> provide access to SMIv2 instrumentation, I believe we are in trouble.

I agree.  I think it's our responsibility as a standards body NOT to get into 
this trouble if it's avoidable (which I think it is).  It seems to me we 
should able to agree to a single representation of existing SMI datatypes.  
The trick seems to be deciding that we will...

 >   two translation paths is consistent.

That'd certainly be my preference.

Cheers,

David

---

From: David Partain <[email-masked]>
Date: Thu, 24 Jul 2008 13:35:24 +0200

Hi,

Cheers,

David

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 24 Jul 2008 14:39:36 +0200

Hello,
I see two immediate users of the datatypes: XSD in new drafts e.g. Netconf Monitoring, and the 
DSDL mapping. They can either:
- Assume solution b) coordinated, consistent datatypes
- Start working on draft-wonderful-xsd-datatypes-for-netconf
The latter will need extra work, time and authors.
balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 24 Jul 2008 14:39:36 +0200

Hello,

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 24 Jul 2008 23:32:12 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:

> YANG inet:host definition into XSD?

The inet:host XSD is in fact just an (automatic) translation of the
corresponding types from the "inet-types" YANG module.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 24 Jul 2008 23:32:12 +0200 (CEST)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Jul 2008 10:53:57 +0200

> corresponding types from the "inet-types" YANG module.

So then the differences I see are 'just' version differences.

I am still feeling uneasy that we have a non-normative YANG source
module that imports other YANG modules, we apply a translation
algorithm to it that is under definition, and the resulting XSD output
we post for standardization. And alFrom [email-masked]  Fri Jul 25 01:54:09 2008
Date: Fri, 25 Jul 2008 10:53:57 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Mail-Followup-To: Martin Bjorklund <[email-masked]>,
	[email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Reply-To: [email-masked]
Sender: [email-masked]

> corresponding types from the "inet-types" YANG module.

So then the differences I see are 'just' version differences.

I am still feeling uneasy that we have a non-normative YANG source
module that imports other YANG modules, we apply a translation
algorithm to it that is under definition, and the resulting XSD output
we post for standardization. And all this is done without being
described in the document nor is there a clear statement that the XSD
is (or is meant to be) identical to other YANG definitions.

/js

l this is done without being
described in the document nor is there a clear statement that the XSD
is (or is meant to be) identical to other YANG definitions.

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 25 Jul 2008 09:48:58 +0200

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 24, 2008 9:55 AM
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

> answer the above questions for each of these examples?

At the risk of stating the obvious, because the on-the-wire encoding sets out to
be different.  BER.1, for good reasons, is a binary encoding, XML, for equally
good reasons, uses a character encoding, so what is on the wire is bound to be
different.  We could have preserved the ASN.1 and gone for a different,
character-based encoding, but didn't - we chose XML and I think that Bob's I-D
reflects that.

What should be preserved across the transformation(s), be they SMIv2 to XML or
SMIv2 to ........ to XML are the abstract concepts of the data model, the
ASN.1-ness and not the on-the-wire encoding.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Fri, 25 Jul 2008 09:48:58 +0200

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 24, 2008 9:55 AM
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Fri, 25 Jul 2008 11:58:28 -0400

Hi,

The problem is, the tools make some decisions to "improve" the
definition rather than provide a faithful translation of the SMIv2
definition. 

I have not tested the tool's BridgeId translation from the BRIDGE-MIB
definition to the tool's output, but I assume you used libsmi to
generate the YANG-LIB definition, which changes the format from the
IETF/IEEE standardized format to an "improved" proprietary text-based
format.

If the tools do not provide a faithful translation of the standard,
then I do not think we should rely on the tools to provide the
"standard" translation.

dbh

> Sent: Thursday, July 24, 2008 3:45 AM
> To: Romascanu, Dan (Dan)

---

From: "David Harrington" <[email-masked]>
Date: Fri, 25 Jul 2008 11:58:28 -0400

Hi,

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Jul 2008 19:56:03 +0200

> definition rather than provide a faithful translation of the SMIv2

I will ignore the word 'faithful' until someone provides a decent
definition of it.
 
> generate the YANG-LIB definitFrom [email-masked]  Fri Jul 25 10:56:13 2008
Date: Fri, 25 Jul 2008 19:56:03 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: David Harrington <[email-masked]>
Mail-Followup-To: David Harrington <[email-masked]>,
	"'Romascanu, Dan (Dan)'" <[email-masked]>,
	"'Natale, Bob'" <[email-masked]>,
	'Sharon Chisholm' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Reply-To: [email-masked]
Sender: [email-masked]

> definition rather than provide a faithful translation of the SMIv2

I will ignore the word 'faithful' until someone provides a decent
definition of it.
 
> generate the YANG-LIB definition, wion, which changes the format from the

You guessed wrong. But the whole point is that the SMIv2 BridgeId
defines a binary reprentation; in XML you have to render binary data
into something textual. SMIv2 does not define a textual rendering for
BridgeId. I defined one which I thought matches existing CLIs and what
operators are used to. If you do not like it, make a constructive
counter proposal - otherwise we are wasting energy.

Yours faithfully,

/js

hich changes the format from the
> IETF/IEEE standardized format to an "improved" proprietary text-based

You guessed wrong. But the whole point is that the SMIv2 BridgeId
defines a binary reprentation; in XML you have to render binary data
into something textual. SMIv2 does not define a textual rendering for
BridgeId. I defined one which I thought matches existing CLIs and what
operators are used to. If you do not like it, make a constructive
counter proposal - otherwise we are wasting energy.

Yours faithfully,

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 25 Jul 2008 14:25:25 -0400

Hi,

I have copied this to the netmod and opsawg WG mailing lists, since
that is where datatype libraries should be discussed.

You only see two immediate uses for SMIv2 datatypes in XSD because you
only work on netconf standards.

How about datatypes for my SNMP NMS that has an XML/XSD-capable
database? Why do I have to wait for the Netmod WG to finish designing
a language **specifically for use with netconf** before I can have a
standard XSD to work with my SMIv2 datatypes in an SNMP-focused
application?

How about the <name a company> implementing netconf that needs/wants
to define XML-based datamodels to use with netconf, as suggested by
RFC4741, and the company wants to leverage all the SMIv2 MIB support
it already has available in its products and wants a standardized
translation of SMIv2 datatypes NOW, not in 3-5 more years.

Real world: the IETF network management world does not revolve around
YANG. For 20 years, it has revolved around SMI datatypes, not YANG
datatypes.

XSDMI is an OPSAWG work item. 
We have already had this discussion mutliple times, and reached
consensus to do XSDMI independent of YANG, but with an effort to
coordinate with YANG.
XSDMI is just about ready for WGLC.
Netmod WG is finally going to have its first WG meeting. 
Netmod WG will not realistically finish anytime soon.
And the IESG might eventually decide to not approve netmod's YANG
language as a standard. 
So why does the whole SNMP community need to wait for
SMIv2->YANG->XSD?

If the available tools generate SMIv2->XSD translations that are
valid, 
and the tools generate SMIv2->YANG->XSD translations that are valid
but different, 
then either the YANG translation rules got it wrong
or the YANG tools are trying to solve a different problam than the
SMIv2->XSD translation.
If I want a direct translation from SMIv2->XSD, why do I have to use
YANG tools to do this?

Juergen's suggested approaches include b) which is "coordinated" and
c) which is "painful". I think this is a false characterization. b) is
"painful" to those who have to wait possibly much longer for standard
datatypes, especially for non-netconf applications, and c) and d)
still have "coordination" so that the result is consistent. 

XSDMI has already slowed down its work by months to deliberately
coordinate its work with the YANG datatypes work, so the two are very
close already. Why don't we eliminate YANG-LIB and DSDL datatype work
from netmod, and standardize SMIv2 "faithful" datatypes (i.e., with no
netconf-specific "improvements") in XSDMI/OPSAWG (possibly using
translation rules rather than hand translations) and then netmod
(YANG, XML-on-the-wire, and the DSDL mapping) can use the OPSAWG
standard datatype library? That way, a standard datatypes library
could be available much sooner for applicability to netconf,
non-netconf, netmod and non-netmod uses rather than making everybody
wait for netmod.

If you are convinced that netmod will add some specific requirements
that we don't even know about yet, then let's not make XSDMI and the
SNMP community and the non-YANG Netconf community wait for netmod to
decide what those are since they are obviously not requirements of
SMIv2, and XSDMI is all about SMIv2, not netmod.

dbh

> Sent: Thursday, July 24, 2008 8:40 AM
> To: Romascanu, Dan (Dan); David Harrington; Natale, Bob; 
> Sharon Chisholm; [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Fri, 25 Jul 2008 14:25:25 -0400

Hi,

dbh

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Jul 2008 20:41:02 +0200 (CEST)

> is (or is meant to be) identical to other YANG definitions.

Agreed.  An XML-version of "host" (union of domainname, ipv4, ipv6) is
needed now for the monitoring draft.  Do you have a suggestion for how
to solve this?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Jul 2008 20:41:02 +0200 (CEST)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Jul 2008 11:46:19 -0700

Juergen Schoenwaelder wrote:
> operators are used to. If you doFrom [email-masked]  Fri Jul 25 11:46:27 2008
Date: Fri, 25 Jul 2008 11:46:19 -0700
From: Andy Bierman <[email-masked]>
To: David Harrington <[email-masked]>, 
	"'Romascanu, Dan (Dan)'" <[email-masked]>,
	"'Natale, Bob'" <[email-masked]>, 
	'Sharon Chisholm' <[email-masked]>, [email-masked]
Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Sender: [email-masked]

Juergen Schoenwaelder wrote:
> operators are used to. If  not like it, make a constructive

It could be encoded as hexBinary or base64Binary, but...

IMO, this entire approach to SMIv2 data type usage is broken
because the definitions are moving to a different module.
In YANG, that's a big deal.  In XSD conversion, it means tools
will need to be hard-wired to change IMPORTS for certain 'special' TCs,
and hide the real definitions from use.

For example, any translated MIB that uses InetAddress will
be importing it from INET-ADDRESS-MIB.  Any new module
that uses the new data types can not really be integrated
with existing modules that do not use the new versions.

IMO, the data types in the libsmi translated INET-ADDRESS-MIB.yang
follow the SMIv2 translation as faithfully as possible,
and the correct module name is maintained.

An algorithmic approach to SMIv2 integration is needed,
that describes how to convert every data type
and every TC that has ever been written, or could be written.
This is probably too hard to standardize, even though there is
running code that can do it.

Since the IETF is intent on pursuing this work, at least
consider this problem.

Andy

you do not like it, make a constructive
> counter proposal - otherwise we are wasting energy.

It could be encoded as hexBinary or base64Binary, but...

IMO, this entire approach to SMIv2 data type usage is broken
because the definitions are moving to a different module.
In YANG, that's a big deal.  In XSD conversion, it means tools
will need to be hard-wired to change IMPORTS for certain 'special' TCs,
and hide the real definitions from use.

For example, any translated MIB that uses InetAddress will
be importing it from INET-ADDRESS-MIB.  Any new module
that uses the new data types can not really be integrated
with existing modules that do not use the new versions.

IMO, the data types in the libsmi translated INET-ADDRESS-MIB.yang
follow the SMIv2 translation as faithfully as possible,
and the correct module name is maintained.

An algorithmic approach to SMIv2 integration is needed,
that describes how to convert every data type
and every TC that has ever been written, or could be written.
This is probably too hard to standardize, even though there is
running code that can do it.

Since the IETF is intent on pursuing this work, at least
consider this problem.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Jul 2008 22:38:17 +0200 (CEST)

> translation of SMIv2 datatypes NOW, not in 3-5 more years.

Several companies already do this, in proprietary ways.  But the
datatype translation is just one part (maybe the easy one).  Other
things to consider for a standard SMIv2->XML mapping are: what does
the XML structure look like?  What is the top-level element for a
given MIB?  Which namespace URI is used?  How are INDEXes encoded?
How are INDEXes in foreign tables encoded?  How is RowStatus handled?
How is StorageType handled?

I think it has been said before, but I would rather see a mapping of
SMIv2 (types and structure) to XML, than XSD.  If there was a mapping
to XML, tools could generate compliant XSD, RNG, or YANG.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Jul 2008 22:38:17 +0200 (CEST)

/martin