Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (-08)

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 11 Apr 2008 14:12:52 +0200

Dear Pasi, all,

My name is Thomas Dietz and I designed the new XML Schema for this draft. I
will also help to finish this draft. So find my comments to these open
issues inline.

-- 
Thomas Dietz                 E-mail: [email-masked]
NEC Europe Ltd.              Phone:  +49 6221 4342-128
NEC Laboratories Europe      Fax:    +49 6221 4342-155
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg, Germany    http://www.nw.neclab.eu

NEC Europe Limited           Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Mittwoch, 5. März 2008 13:02
> To: Saverio Niccolini; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Sandra Tartarelli; Juergen
> Quittek; [email-masked]; Thomas Dietz
> Subject: RE: Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (-
> 08)
> 
> Saverio Niccolini wrote:
> 
> > > About #5: TestName uniqueness/scope is still very different
> > > from RFC 4560 (in RFC 4560, test name *alone* is not unique;
> > > it's combined with traceRouteCtlOwnerIndex, contextEngineID,
> > > and contextName).  However, if the results are not converted
> > > from SNMP MIB, other methods of specifying the scope might be
> > > useful (e.g. host name or IP/MAC address or something).
> > >
> > > The specification of testName scope is related to one *very*
> > > important information element that is currently missing from
> > > the schema: where the measurements were run. Note that
> > > current semantics of CtlSourceAddress make it unusable for
> > > this purpose. In RFC 4560, the scope is given by
> > > contextEngineID and contextName (which can be used to look up
> > > more information from  e.g. Interfaces, IP, or Entity MIBs)
> > > -- here it needs to be explicit.
> >
> > We can not make the scope the same as RFC 4560, we can jsut choose
> > it as if it was chosen in accordance with RFC 4560 since the
> > constructs contextEngineID and contextName are MIB-specific.  We
> > discussed this and we think this is the best way of solving it, if
> > you have a concrete suggestion we are ready to implement it.
> 
> Well... let me ask it this way: when you get an XML file containing
> results from a traceroute run, do you think it's important to know
> on which host the measurement was run on?
> 
> (I think it would be -- but if the WG consensus is that this
> information is unimportant, then at least the document needs to
> explain this quite surprising omission, and Appendix C needs
> to describe this big difference to RFC 4560.)
> 

Well, I don't think that the current situation for the TestName is really
different from what is defined in RFC 4560. RFC 4560 specifies 2 indexes,
which are traceRouteCtlOwnerIndex and traceRouteCtlTestName.
traceRouteCtlOwnerIndex is only used for simple access control to the
elements in the traceRouteCtlTable and thus traceRouteCtlName is the only
object that specifies the test.

You can argue that the host is implicitly given since you query it by SNMP.
So we have 2 possibilities to solve this issue:

1 - Add a kind of scope element to the schema
2 - Or leave the schema as it is and state that the host (or similar
information) is encoded in the filename

> > > About #9: I still believe it should be possible to add new
> > > CtlTypes without making the XML file unparseable by
> > > existing software.
> >
> > We think differently and that is why we added the following sentence:
> > " It specifies if the traceroute is using TCP, UDP, ICMP or others
> > type of probes.  If these needs to be extended then a new schema
> > needs to be defined with re-definitions of CtlType and related
> > response status."
> > We do not see other way out of it.
> 
> Could you explain in more detail what you mean by "we do not see
> other way of of it"?
> 

To make the CtlTypes extensible is really a difficult thing. There are 2
possibilities I currently have in mind.

One is to have a CtlTypes value of "other" (as it is now) and add an element
called e.g. CtlTypeOther where you can specify which other type it is. This
would make the schema more complicated.

The other is to remove the CtlTypes value of "other" and require an updated
schema (which can be really short by just including the original one,
redefining the CtlTypes element and adding additional elements needed).

I would prefer the second one because it corresponds to the method of RFC
4560. In RFC 4560 you require an OID for the traceRouteCtlType. Further on
the RFC says:

           Additional implementation types should be allocated as
           required by implementers of the DISMAN-TRACEROUTE-MIB
           under their enterprise specific registration point,
           not beneath traceRouteImplementationTypeDomains.

This means an enterprise specific MIB is needed to implement a new
traceRouteCtlType. A similar approach would be to require an updated schema.

> > > My comment #23 (should have a reference about SO_DONTROUTE)
> > > is still valid.
> >
> > I have added the sentence: "This object can be used when the
> > setsockopt SOL_SOCKET SO_DONTROUTE option is supported and set."  I
> > hope this is specific enough
> 
> I was hoping for a reference to a document.
> 

We will include a reference. Best should be IEEE 1003.1G (POSIX).

> > > Additional comments for this version:
> > >
> > > 24) The informational model has changed quite a lot in this
> version.
> > > In particular, in version -08 each XML file contained results
> > > from a single traceroute measurement, while it seems in -09
> > > several measurements (with their own TestName, target
> > > address, etc.) can be included, as long as they share the
> > > same parameters.
> > >
> > > Is this an intentional change that resulted from WG
> > > identifying a new requirement, or just an accident in schema
> > > editing?  (Having just single measurement run makes this
> > > simpler, so unless this is really an important requirement,
> > > I'd suggest not adding features of this magnitude at this stage.)
> >
> > I think it is an important requirement and was an error not to
> > be included from the beginning, that is why we changed it now
> > that we re-designed the schema
> 
> I think you need to check this with your AD, as you need
> to make sure you have WG consensus behind this change.
> 

For sure we need consensus for this but we think the improved readability is
worth it.

> Also, are you quite sure that the contents of MeasurementResult
> element (1..2550 ProbeResults elements and 0..255
> ResultsHopRawOutputData
> elements) is correct? Or should this be exactly 1 ProbeResults element?
> (Given that a single ProbeResults contains 1..255 hop elements, and
> each hop element can contain 1..10 probe elements?)
> 

The RFC 4560 defines a similar structure. It has a history of 1 -
maxUnsignedInt entries containing 1 - 255 hp elements with 1 - 10 probe
elements. I agree that the ResultHopRawOutputData should be moved to the
_ProbeResults data type. We will adjust the restrictions that do not match
the RFC 4560.

> > > 25) _RequestMetadata has a number of elements with
> > > minOccurs="0", but the informational model doesn't describe
> > > the semantics of omitting the element. (Note that RFC 4560
> > > does specify the default value for almost all of these.)
> >
> > I have added a sentence: "If the "RequestMetadata" element is
> > omitted from an XML file then it means that the traceroute
> > measurement configuration parameters requested were all used
> > and the "MeasurementMetadata" element list them in detail."
> 
> My concern was omitting child elements of RequestMetadata, such
> as CtlBypassRouteTable, CtlProbeDataSize, etc.
> 

We will update this and require all elements but give them a default value
so that you can just give an empty element if the according element was not
specified at the invocation of the traceroute command.

> > > 26) the definition of "inetAddress" type in XML schema
> > > doesn't match the information model in Section 5.
> >
> > Section 5 says: "InetAddress - The type "InetAddress" denotes a
> > generic Internet address.  The allowed values are imported from
> > <xref target="RFC4001"/> (the values imported are unknown, ipv4,
> > ipv6 and dns), while non-global IPv4/IPv6 addresses (e.g. ipv4z and
> > ipv6z)were ecluded; an additional allowed value is the AS number to
> > be indicated as the actual number plus the indication how the
> > mapping from IP address to AS number was performed. "unknown" is
> > used to indicate an IP address that is not in one of the formats
> > defined."
> >
> > and the schema defines:
> >
> > inetAddressUnknown
> > inetAddressIpv4
> > inetAddressIpv6
> > inetAddressASNumber
> > inetAddressDns
> >
> > I think it matches.
> 
> No, it doesn't: in the information model, "InetAddress" is exactly
> one of (unknown, ipv4, ipv6, dns, asnumber, unknown). In the schema,
> it can contain *both* ipv4 address and dns name (since the
> inetAddressDns element is outside the xs:choice group).
> 

The intention was to say behind every numerical address could be a DNS name.
But to be consistent with the information model and RFC 4560 we will change
that.

> > > 28) "ProbeRoundTripTime" / "_roundTripTime" data
> > > type/restrictions is not aligned with RFC 4560.
> >
> > That does not mean it is wrong :-)
> 
> No, but it means that RFC 4560 information can't be necessarily
> converted to XML. If this is intentional, it should be mentioned
> in Appendix C.
> 

You are right data type and restriction does not match RFC 4560. We will
align this with the RFC.

Best Regards,

Thomas

> Best regards,
> Pasi
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Mon, 14 Apr 2008 12:56:45 +0300

Thomas,

Thanks for taking the time to help with finishing this draft!
See my comments in-line:

<snip>
> Well, I don't think that the current situation for the TestName is
> really different from what is defined in RFC 4560. RFC 4560
> specifies 2 indexes, which are traceRouteCtlOwnerIndex and
> traceRouteCtlTestName.  traceRouteCtlOwnerIndex is only used for
> simple access control to the elements in the traceRouteCtlTable and
> thus traceRouteCtlName is the only object that specifies the test.
> 
> You can argue that the host is implicitly given since you query it
> by SNMP.  So we have 2 possibilities to solve this issue:
> 

Or simply say that TestName is not necessarily unique within any
well-defined scope?

(BTW, the CtlSourceAddress annotation has slightly unclear sentence 
"A zero length octet string value for this object means that source
address specification was disabled." The past tense suggests this
applies to MeasurementMetadata, but it seems it was intended
to apply to RequestMetadata only.)

<snip>

> > > We think differently and that is why we added the following
> > > sentence: " It specifies if the traceroute is using TCP, UDP,
> > > ICMP or others type of probes.  If these needs to be extended
> > > then a new schema needs to be defined with re-definitions of
> > > CtlType and related response status."  We do not see other way
> > > out of it.
> > 
> To make the CtlTypes extensible is really a difficult thing. 

This kind of situation (small set of predefined values, which needs to
be extensible later) occurs in many IETF-defined XML schemas, and
solving it has not been difficult before.  I'm trying to understand
what makes this particular situation more difficult than the others.

> There are 2 possibilities I currently have in mind.
> 
> One is to have a CtlTypes value of "other" (as it is now) and add an
> element called e.g. CtlTypeOther where you can specify which other
> type it is. This would make the schema more complicated.
>
> The other is to remove the CtlTypes value of "other" and require an
> updated schema (which can be really short by just including the
> original one, redefining the CtlTypes element and adding additional
> elements needed).
>
> I would prefer the second one because it corresponds to the method
> of RFC 4560. In RFC 4560 you require an OID for the
> traceRouteCtlType. Further on the RFC says:
> 

This enterprise MIB would define just an OID; it would not move the
existing tables from their current location (1.3.6.1.2.1.81).

The closest XML analogy would probably be defining a new CtlType value
(in enterprise specific schema, corresponding to enterprise specific
namespace), but keeping all the current elements in the same namespace
they're now.

This sounds like one reasonable approach, and would be quite easy to
do. The resulting XML would then probably look something like this:

  <CtlType><Tcp/><CtlType>

or

  <CtlType xmlns:foo="http://example.com/FooSchema"> 
    <foo:FooType/>
  <CtlType>

(the schema needs some kind '<xs:any namespace="##other">' 
element).

In my earlier emails, I also suggested two very simple approaches that
have been used in IETF XML schemas before. Could you comment on why
you believe neither of those is appropriate for this situation?

(First approach, used in e.g. RFC 3275, is to base CtlType on
xs::anyURI, and specify three (non-resolvable) URIs for TCP, UDP, and
ICMP. Second approach, used in e.g. RFC 4119, is to base CtlType on
xs::token, and and let IANA manage the values, with initial values
being "TCP", "UDP", and "ICMP").

Best regards,
Pasi

---

From: Lars Eggert <[email-masked]>
Date: Tue, 29 Apr 2008 15:52:49 +0300

Authors,

could you please respond to Pasi's suggestions and/or submit a new  
revision?

Thanks,
Lars

---

From: "Thomas Dietz" <[email-masked]>
Date: Tue, 29 Apr 2008 17:03:15 +0200

Hello Pasi,

Sorry for the late reply. Find my answers inline.

> Sent: Montag, 14. April 2008 11:57
> To: Thomas Dietz; Saverio Niccolini; [email-masked];
> [email-masked]
> Quittek; [email-masked]

OK, so we will change this.
> being "TCP", "UDP", and "ICMP").

Sorry, I did not see those e-mails. Either they did not go to the list or I
missed them while reading the archive. Both approaches look fine. I think I
prefer the first one because then enterprises can define their own CtlTypes.

Best Regards,

Thomas