[MIB2RDML] FW: [OPS-AREA] Expressing SNMP SMI Datatypes in XML Schema Definition Language draft submitted

Forwarding to the "MIB2RMDL" list (which was misnamed as "MIB2RDML" on
list setup time somehow :).

-----Original Message-----
From: Natale, Bob 
Sent: Monday, March 10, 2008 11:55 AM
To: 'ellison@ieee.org'
Cc: opsawg@ietf.org; 'mib2rmdl@ietf.org'; OPS Area
Subject: RE: [OPS-AREA] Expressing SNMP SMI Datatypes in XML Schema
Definition Language draft submitted

Hi Mark,

Thanks for the review feedback.  Responses inline below and will be
incorporated in the next (-02) rev, due out in a week or so.  Please
let me know if you (anyone) disagree with intended disposition of any
of your comments.

Cheers,
BobN

-----Original Message-----
From: Mark Ellison [mailto:mark@EllisonSoftware.com] 
Sent: Saturday, March 01, 2008 6:20 PM
To: Natale, Bob; liyan_77@huawei.com
Cc: OPS Area
Subject: Re: [OPS-AREA] Expressing SNMP SMI Datatypes in XML Schema
Definition Language draft submitted

Hi Bob and Yan,

I have the following comments on the smi-2-xsd ID for you:

    section 4,  "XSD for SMI Datatypes" - general comment on mappings: 
    If "on the wire" encodings are represented here, then ought there
be
    a mapping for "SEQUENCE" since it appears on the wire.  If not,
then
    a mention of why not in the ID would be good.

<BobN>
I will make it clear in the text that this draft concerns only the 10
"ObjectSyntax" datatypes defined in RFC2578, used for the purposes of
representing the "on-the-wire" values carried in SNMP PDUs.

The SEQUENCE syntax mapping *might* make an appearance in the
"Structures" document, if needed there.  Textual convention syntax
mapping to XSD will appear in the "TCs" document.
</BobN>

    section 4,  "XSD for SMI Datatypes" - general comment on mappings; 
    I agree these mappings closely follow "on the wire" encodings. 
    However, I wonder if it is worthwhile to map the Counter and Gauge
    semantics onto a restriction base that includes some notion of the
    semantic behavior of a counter or a gauge.  This would conceptually
    extend the base type with an xml tag indicating counter or gauge
    semantics.

<BobN>
Will consider.  For now, the thinking is that correct raw data mapping
of singular values is the target for this document.  The problem with
bringing in application-level semantics is "where do you stop?".  In
any case, I will definitely add some "appInfo" annotations that will
help to address the point you make here.
</BobN>

    section 4,  "XSD for SMI Datatypes" - at the top of page 7, the pro
    forma URN,  "urn:ietf:params:xml:ns:opsawg:smi:v1.0", is probably
    technically correct, but may cause cognitive dissonance as it reads
    too easily as "SMIv1" while we are for mapping SMIv2.

<BobN>
You are right, but it might be unavoidable.  I would all interested
parties to know that this is a specific [TODO] item that I could use
guidance on.  At this time, I think I can resolve all the [DISCUSS] and
[TODO] items in the -01 version for the -02 version, except possibly
this one.
</BobN>

    section 6, "Security Considerations" - I think the functions of the
    USM and the VACM would map onto mechanisms within a SOAP envelope
    header.  I suppose "special care" is sufficient wording for ID
    purposes at hand, but wonder if it is also worth identifying the
    appropriate mapping point for these security considerations.

<BobN>
I will try to add some helpful text along the lines of your comment.
USM and VACM are not *directly* relevant for the scope of this document
(see response to your second comment above).  Probably not for the
"TCs" document either.  Whether we will need to include consideration
of "gateway" topics in the "Structures" document is something I just
don't know right now...and am hopeful of having plenty of help with at
the time. :)
</BobN>

Regards,

Mark

On 02/11/2008 03:18 AM, Natale, Bob wrote:
> Hi,
>  
> I have submitted "Expressing SNMP SMI Datatypes in XML Schema 
> Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt, 
> via the Internet-Drafts submission tool, but had to do it via a 
> "manual entry" due to administrative complications.  Manual 
> submissions can take up two business days to process.
>  
> In the meantime, I have posted a copy at 
>
http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi-datatypes-in-x
sd-00.txt 
>
<http://home.comcast.net/%7Ebobnatale/draft-ietf-opsawg-smi-datatypes-i
n-xsd-00.txt>.
>  
> For those who might want to review the slides I presented at the 
> Vancouver IETF for background info, you can get them at 
>
http://home.comcast.net/~bobnatale/Converting_SNMP_MIBs_to_XML_via_XSD.
ppt 
>
<http://home.comcast.net/%7Ebobnatale/Converting_SNMP_MIBs_to_XML_via_X
SD.ppt>.  
> The I-D has updated wording relative to the slides.  Slide 7 helps to

> narrow the focus of the current effort relative to the original 
> MIB2RMDL scope on slide 6.
>  
> Apologies for cross-posting to the ops-area list -- this is an "Ops 
> Area WG" and "MIB2RMDL" item, but just wanted to be sure to alert all

> interested parties without going too far afield.
>  
> Cheers,
> BobN
>  
>  
>
-----------------------------------------------------------------------
-
>
> _______________________________________________
> OPS-AREA mailing list
> OPS-AREA@ietf.org
> http://www.ietf.org/mailman/listinfo/ops-area
>   

_______________________________________________
MIB2RDML mailing list
MIB2RDML@ietf.org
https://www.ietf.org/mailman/listinfo/mib2rdml