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.) > > 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"? > > 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. > > 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. 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?) > > 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. > > 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). > > 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. Best regards, Pasi _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
