Hello Pasi, Sorry for the late reply. Find my answers 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: Montag, 14. April 2008 11:57 > To: Thomas Dietz; Saverio Niccolini; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Cc: [email protected]; [EMAIL PROTECTED]; Sandra Tartarelli; Juergen > Quittek; [EMAIL PROTECTED] > Subject: RE: Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (- > 08) > > 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.) > OK, so we will change this. > <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"). > 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 > Best regards, > Pasi
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
