Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72

[Andy Bierman <[e-mail]>]

Bert Wijnen (IETF) wrote:
> Thanks Juergen for your follow up.
>  
> I have responded to Mark (privately) that we actually had a gentlemens 
> agreement at
> the last IETF that he would try to get some interested folk in this 
> space together
> to analyze, study the topic and alternatives and that that small group 
> would then
> document one or more possile solutions and explain the pros/cons of each.
>  
> I hope that that effort will still take place (albeit somewhat later 
> that we wanted)
>  
> I also urge those who want to do that work (analyze, document the 
> alternatives,
> make some well-documented proposals) to get in tocuh with Mark.
> You can copy the WG list (or just the WG chairs) if you want.
>  

Creating multiple data model representations of an address
is not acceptable.  I raised this issue 3 or 4 IETFs ago,
and the 'quick-fix' solution is still not available.

The most basic data structure in the entire IETF is
the InetAddress.  If we can't settle on a typedef for an
InetAddress after all this time, that is pretty sad.

Listen to Juergen.  He is right, and we should use
inet-types.yang typedefs and patterns.  This issue
has already been studied, examined, and delayed long enough.

> Bert

Andy


> 
>     ----- Original Message -----
>     *From:* Juergen Schoenwaelder
>     <mailto:[e-mail]>
>     *To:* Mark Scott <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *Sent:* Wednesday, October 22, 2008 4:06 PM
>     *Subject:* Re: [Netconf] [NETCONF] monitoring data type
>     definitions;proposed resolution to open item from IETF72
> 
>     On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote:
>      
>      > An open item discussed at IETF 72 is the definition of data types
>     in the
>      > monitoring draft.  Specifically whether or not data types required in
>      > the model should be explicitly defined in this draft or whether they
>      > should reference other standardized XSD definitions (where they
>     exist).
>      > 
>      > In particular draft-ietf-netconf-monitoring-02 currently contains an
>      > explicit definition for an IP address data type.  This can be
>     found in
>      > sec 5.2 of the draft.  I have also included it below for reference.
>      > 
>      > Rationale at the time of authoring v02 was to explicitly define this
>      > since no other standardized XSD was available.  Although I am
>     aware of
>      > similiar work in-progress to define standardized XSD data types I am
>      > still now aware of one suitable for this draft at this time.
> 
>     Do you have a list of work in progress documents where similar XSD
>     definitions are provided?
> 
>      > The item which looked most promising (which was discussed in
>     Dublin) was
>      > alignment to the definitions in
>      > draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4).  That draft
>     focuses
>      > on representing existing SMI datatypes in XSD.  This in
>     insufficient for
>      > the needs of the monitoring draft where we require an enhanced
>      > definition.  In particular one with the ability to handle both
>     IPv4 and
>      > IPv6 addresses.
>      > 
>      > So I would like to seek concencus from the group that the current
>      > explicit definition in draft-ietf-netconf-monitoring-02 is sufficient
>      > for our NETCONF monitoring needs and that we will leave the explicit
>      > definition in the draft in the next update (-03).
> 
>     Some questions:
> 
>     a) What is going to be the final scope of this? Are these definitions
>        going to be NETCONF monitoring specific only or are there
>        expectations that these definitions are used in the wider context
>        of the IETF? (The suggested namespace might imply a much wider
>        context.)
> 
>     b) I see differences in the patterns compared to what we have in
>        draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in
>        the appendix). Perhaps this should be synchronized.
> 
>     c) In the context of the YANG work, we recently discussed the issue of
>        types allowing multiple representations for a single value from the
>        value space. This leads to the question of normalization. For
>        example, IPv6 addresses can be represented in different ways, e.g.,
>        ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a
>        NETCONF implementation only maintains the value and not its
>        representation, is there a normalized representation you can expect
>        to be returned by the NETCONF server? Since you are dealing with
>        IPv6 addresses, you might have to deal with the same issue (and not
>        surprisingly, I like the NETCONF monitoring document to be
>        consistent with the YANG types document about this issue).
> 
>     /js
> 
>     -- 
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
>     Fax:   [phone]         <http://www.jacobs-university.de/>
>     _______________________________________________
>     Netconf mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netconf
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf


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