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 PROTECTED] 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 PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 5. März 2008 13:02 > To: Saverio Niccolini; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [email protected]; [EMAIL PROTECTED]; Sandra Tartarelli; Juergen > Quittek; [EMAIL PROTECTED]; 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
