Subject: [OPSAWG] iesg changes to smi-datatypes

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 25 Apr 2010 14:25:12 +0200

Hi,

the IESG writeup says:

OLD: 

   Values in varbinds corresponding to MIB objects defined with TC
   syntax are always encoded as the base SMI datatype underlying the TC
   syntax.  Thus, the XSD mappings defined in this memo provide support
   for values of MIB objects defined with TC syntax as well as for
   values of MIB objects defined with base SMI syntax.

NEW: 

   Values in varbinds corresponding to MIB objects defined with TC
   syntax are always encoded as the base SMI datatype underlying the TC
   syntax.  Thus, the XSD mappings defined in this memo provide support
   for values of MIB objects defined with TC syntax as well as for
   values of MIB objects defined with base SMI syntax. Using the 
   translation of TC into base SMI datatypes any MIB module that uses 
   TCs can be mapped into XSD using the mappings defined in this memo. 
   For example for IP addresses (both IPv4 and IPv6) the  mapping of the
   InetAddress TC (as per [RFC4001]) shall be used rather than the 
   mapping of the IpAddress base datatype.

Note that the document says elsewhere (section 5.4):

   Note that the SMI relies upon Textual Conventions (TCs) to specify an
   IPv6 address.  As such, the representation of an IPv6 address as an
   XSD datatype is beyond the scope of this document.

This sounds inconsistent to me.

Even worse, the new text seems to imply that mapping to the base type
is the way to represent TCs, which means everything defined with a
base type OCTET STRING is represented as a hexBinary. This might be a
rather poor choice overall and this also seems to be different from
what real world tools do with TCs. I believe the document should state
that mappings of TCs is subject to further documents, as it does in
section 1:

   [...] Developers of
   other XML-based management applications may need to make more
   complete reuse of existing MIB modules, requiring standard XSD
   documents for TCs [RFC2579] and MIB structure [RFC2578].  Memos
   supporting such requirements are planned, but have not been produced
   at the time of this writing.

I also note that this sentence is somewhat pointless:

   For example for IP addresses (both IPv4 and IPv6) the mapping of the
   InetAddress TC (as per [RFC4001]) shall be used rather than the
   mapping of the IpAddress base datatype.

We are talking about mappings; so we either map an IpAddress or an
InetAddress - there is not choice. I believe the original text in
section 5.4 is just right on the spot.

/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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 25 Apr 2010 16:23:35 +0200

Hi Juergen,

See in-line. 

Regards,

Dan

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Sunday, April 25, 2010 3:25 PM
> To: [email-masked]; Romascanu, Dan (Dan); Mark Ellison
> Cc: [email-masked]
> Subject: iesg changes to smi-datatypes
> 
> Hi,
> 
> the IESG writeup says:
> 
> OLD: 
> 

The proposed text was a response to the DISCUSS raised by Jari, and
allowed him to clear his DISCUSS. The concern raised by Jari was that
the RFC is providing a mapping for IPv4 addresses and no mapping for
IPv6 addresses. We know that this is the result of IPv4 address being a
base type in the SMI, and the scope of the document mapping only base
types into XSD, but this was not clear to somebody who is not familiar
with the SMI details. The text tries to clarify this, 

> 
> Even worse, the new text seems to imply that mapping to the 
> base type is the way to represent TCs, which means everything 
> defined with a base type OCTET STRING is represented as a 
> hexBinary. This might be a rather poor choice overall and 
> this also seems to be different from what real world tools do 
> with TCs. I believe the document should state that mappings 
> of TCs is subject to further documents, as it does in section 1:
> 
>    [...] Developers of

I do not think that the text implies that mapping to the base type is
the recommended way to represent TCs. It just says that this is a
possibility ('can be mapped'). Would 'could be mapped' be better? 

>    mapping of the IpAddress base datatype.

That's an example and an answer to the concern expressed by Jari which
can be shared by other who may wonder why IPv6 address mapping is
missing.  

> 
> We are talking about mappings; so we either map an IpAddress 
> or an InetAddress - there is not choice. I believe the 
> original text in section 5.4 is just right on the spot.

I do not see a contradiction. Mapping IpAddress is covered because
mapping the base SMI data types is the scope of this document, while
both phrases (new in section 1 and existing in 5.4) point to the TCs.
The phrase in the introduction about mapping TCs 'Memos supporting such
requirements are planned, but have not been produced at the time of this
writing' state where we are at this point in time.

Is the following is more clear? 

OLD: 

NEW: 

  Values in varbinds corresponding to MIB objects defined with TC
  syntax are always encoded as the base SMI datatype underlying the TC
  syntax.  Thus, the XSD mappings defined in this memo provide support
  for values of MIB objects defined with TC syntax as well as for
  values of MIB objects defined with base SMI syntax. Using the 
  translation of TC into base SMI datatypes any MIB module that uses 
  TCs could be mapped into XSD using the mappings defined in this memo. 
  For example for IP addresses (both IPv4 and IPv6) the  mapping of the
  InetAddress TC (as per [RFC4001]) could be used rather than the 
  mapping of the IpAddress base datatype. Other mappings of TCs are 
  subject to future work.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 25 Apr 2010 08:47:31 -0700

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>; <[email-masked]>; "Mark Ellison" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, April 25, 2010 7:23 AM
> Subject: Re: [OPSAWG] iesg changes to smi-datatypes
...
> with the SMI details. The text tries to clarify this, 

It might have been better to say just that, rather than to try add IPv6
support on the spot without digging into the possible consequences
of the approach advocated by the "fix".
 
...
> possibility ('can be mapped'). Would 'could be mapped' be better? 

???  

The new text says "For example for IP addresses (both IPv4 and IPv6) the  
 mapping of the InetAddress TC (as per [RFC4001]) shall be used rather
than the  mapping of the IpAddress base datatype."

This does NOT say "can be mapped."  It says that if one is going
to do IP addresses, the mapping SHALL be that of the InetAddress TC.
The text that's there is stronger than I think you think it is.

...
>   mapping of the IpAddress base datatype. Other mappings of TCs are 

An improvement, but the "example" really doesn't exemplify the topic
of the rest of the paragraph.  It addresses another issue, and seems to
have just been "stuck" there.  IPV6 support is important, but I think it
deserves a paragraph of its own, perhaps giving a little historical background,
and then the example and "subject to future work" health warning.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Sun, 25 Apr 2010 12:38:53 -0400

Hi,

I think there were basically two issues. 

1) Ipaddress only supports IPv4 and not IPv6. 

I recommend in 5.4:
OLD:
   Note that the SMI relies upon Textual Conventions (TCs) to specify
an
   IPv6 address.  As such, the representation of an IPv6 address as an
   XSD datatype is beyond the scope of this document.
NEW:
 Ipaddress can only represent an IPv4 address, and is included in
SMIv2 for historical reasons, as is indicated in RFC2578. The best
current practice for IP address representation in a MIB module is the
InetAddress TC specified in RFC4001, because it can support multiple
address formats, including  IPv4 and IPv6 addresses. The base datatype
representation of an InetAddress value is an OCTET STRING, not an
IpAddress datatype.

Which raised the question:
2) well then, how do TCs get handled until the companion document is
produced? 

I recommend the following text in section 1:
OLD: 

   Values in varbinds corresponding to MIB objects defined with TC
   syntax are always encoded as the base SMI datatype underlying the
TC
   syntax.  Thus, the XSD mappings defined in this memo provide
support
   for values of MIB objects defined with TC syntax as well as for
   values of MIB objects defined with base SMI syntax.
 
NEW: 
   As described in RFC2579, "Objects defined using a textual
convention 
   are always encoded by means of the rules that define their
primitive type.  
   However, textual conventions often have special semantics
associated with
   them." 

   The XSD mappings defined in this document can be used to represent
the 
   values of objects, such as values carried in SNMP varbinds, whether
the
   object was defined using textual conventions or base SMI syntax.

   MIB object definitions often have special semantics associated with
them, 
   whether the definition is written using base SMIv2 macros or using
textual 
   conventions. The definitions specified in a MIB module are often
used to 
   interpret the encoded value, such as whether the value falls within
a valid 
   range. The XSD mappings defined in this document describe the
special 
   semantics of base type object definitions, but not the special
semantics of
   textual conventions. Translating the semantics of textual
conventions into
   XSD will be addressed in one or more future documents.

and
OLD:
  The primary purpose of this memo is to define the standard
expression
   of SMI base datatypes in XML documents that is both uniform and
NEW:
  The primary purpose of this memo is to define the standard
expression
   of SMI base datatype values in XML documents that is both uniform
and
                       ^^^^^^^

dbh

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 25 Apr 2010 18:43:52 +0200

Hi Juergen,

See in-line.

Regards,

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Sunday, April 25, 2010 6:48 PM
> To: [email-masked]
> Cc: [email-masked]
> > To: "Juergen Schoenwaelder" <[email-masked]>; 
> > <[email-masked]>; "Mark Ellison" <[email-masked]>
> > Cc: <[email-masked]>
> > IPv6 addresses. We know that this is the result of IPv4 
> address being 
> > a base type in the SMI, and the scope of the document mapping only 
> > base types into XSD, but this was not clear to somebody who is not 
> > familiar with the SMI details. The text tries to clarify this,
> 
> It might have been better to say just that, rather than to 
> try add IPv6 support on the spot without digging into the 
> possible consequences of the approach advocated by the "fix".
>  
> ...
> The new text says "For example for IP addresses (both IPv4 
> and IPv6) the  mapping of the InetAddress TC (as per 
> [RFC4001]) shall be used rather than the  mapping of the 
> IpAddress base datatype."

Indeed. But what I have in mind is not necessarily mapping via base type
in SMI and  then to XSD, it can be a different mapping that a future
'TCs to XSD' document will define. 

> 
> This does NOT say "can be mapped."  It says that if one is 
> going to do IP addresses, the mapping SHALL be that of the 
> InetAddress TC.
> An improvement, but the "example" really doesn't exemplify 
> the topic of the rest of the paragraph.  It addresses another 
> issue, and seems to have just been "stuck" there.  IPV6 
> support is important, but I think it deserves a paragraph of 
> its own, perhaps giving a little historical background, and 
> then the example and "subject to future work" health warning.

Yes, but from the IESG perspective it is important to say also that a
representation of IPv6 addresses is possible - even if not optimal. A
document that supports only IPv4 addresses should not be approved, and I
think that this is not the case with this document. 

What about this: 

OLD: 

NEW: 

  The mapping of IP addresses is a special case. The base type IpAddress

  in SMI  supports only IPv4, and for IPv4 and IPv6 support the TCs in
  [RFC 4001] were defined. The representation of IPv6 addresses is 
  beyond the scope of this document and subject to future work. 

> 
> Randy
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 25 Apr 2010 18:53:03 +0200

Hi David,

See in-line. 

Regards,

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Sunday, April 25, 2010 7:39 PM
> To: Romascanu, Dan (Dan); 'Juergen Schoenwaelder'; 
> [email-masked]; 'Mark Ellison'; 'Jari Arkko'
> Cc: [email-masked]
> Subject: RE: [OPSAWG] iesg changes to smi-datatypes
> 
> Hi,
> 
> SMIv2 for historical reasons, as is indicated in RFC2578. The 
> best current practice for IP address representation in a MIB 
> module is the InetAddress TC specified in RFC4001, because it 
> can support multiple address formats, including  IPv4 and 
> IPv6 addresses. The base datatype representation of an 
> InetAddress value is an OCTET STRING, not an IpAddress datatype.

This looks OK to me. 

> 2) well then, how do TCs get handled until the companion 
> document is produced? 
> 
>    The XSD mappings defined in this document can be used to 
> represent the 
>    values of objects, such as values carried in SNMP 
> varbinds, whether the
>    MIB object definitions often have special semantics 
> associated with them, 
>    whether the definition is written using base SMIv2 macros 
> or using textual 
>    conventions. The definitions specified in a MIB module are 
> often used to 
>    interpret the encoded value, such as whether the value 
> falls within a valid 
>    range. The XSD mappings defined in this document describe 
> the special 
>    semantics of base type object definitions, but not the 
> special semantics of

I am not sure that all the additional text is necessary because later in
the same section we have the following: 

> Developers of certain XML-based management applications will find
   this specification sufficient for their purposes.  Developers of

>    of SMI base datatype values in XML documents that is both 
> uniform and
>                        ^^^^^^^

Yes.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Apr 2010 10:47:50 +0200

> with the SMI details. The text tries to clarify this, 

To address this concern, there should IMHO not by any changes to section
1 at all. Instead, we need to look at section 5.4. It currently says:

   The XSD "string" datatype is the natural choice to represent an
   IpAddress as XML output.  The "pattern" restriction applied in this
   case results in a dotted-decimal string of four values between "0"
   and "255" separated by a period (".") character.  This pattern also
   precludes leading zeros.

I suggest to rewrite the last paragraph.

OLD:

NEW:

   Note that the SMI relies upon Textual Conventions (TCs) to specify
   an IPv6 address [RFC4001]. Using the translation of TCs into base
   SMI datatypes, any TC can be mapped into XSD using the mappings
   defined in this memo.

This is a one sentence solution that should address the concern while
section 1 leaves it open to develop "more complete" translations in
the future. I can live this this text because it says "can" instead
of "shall", which was triggering my reaction.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 26 Apr 2010 10:53:24 +0200

This looks fine to me.

Dan

> Sent: Monday, April 26, 2010 11:48 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Mark Ellison; [email-masked]
> Subject: Re: iesg changes to smi-datatypes
> 
> This is a one sentence solution that should address the 
> concern while section 1 leaves it open to develop "more 
> complete" translations in the future. I can live this this 
> text because it says "can" instead of "shall", which was 
> triggering my reaction.
> 
> /js
> 
> --

---

From: Jari Arkko <[email-masked]>
Date: Mon, 26 Apr 2010 13:19:32 +0300

I'm OK with it as well.

Jari

Romascanu, Dan (Dan) kirjoitti:

This looks fine to me.

Dan

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

The proposed text was a response to the DISCUSS raised by Jari, and
allowed him to clear his DISCUSS. The concern raised by

Jari was that

address being

To address this concern, there should IMHO not by any changes
to section
1 at all. Instead, we need to look at section 5.4. It currently says:

Note that the SMI relies upon Textual Conventions (TCs) to
specify an
IPv6 address. As such, the representation of an IPv6 address as an
XSD datatype is beyond the scope of this document.

OLD:

Note that the SMI relies upon Textual Conventions (TCs) to
specify an
IPv6 address. As such, the representation of an IPv6 address as an
XSD datatype is beyond the scope of this document.

NEW:

/js