Authors, could you please respond to Pasi's suggestions and/or submit a new revision?
Thanks, Lars On 2008-4-14, at 12:56, Eronen Pasi (Nokia-NRC/Helsinki) wrote: > Thomas, > > Thanks for taking the time to help with finishing this draft! > See my comments in-line: > > <snip> >>>>> 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 > > 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> > >>>>> 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. > > 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: >> >> 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. > > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
