Dear Thomas,
Thanks for updating the draft. This version addresses all my
comments except one:
The description of CtlSourceAddress still has conflicting text
about what the element contains in MeasurementMetadata in case
RequestMetadata didn't request a specific source address.
To clarify my issue slightly: suppose that you didn't request any
particular source address when initiating the traceroute ("source
address specification was disabled"). What does this element contain
in the MeasurementMetadata? The first sentence says it contains the
address actually used; later in the same paragraph, it says the value
"unknown" is used if source address specification was disabled.
These seem to contradict each other.
I think the former is correct here -- otherwise the XML file wouldn't
contain any information about where the traceroute measurement was
run, making it rather useless for most purposes.
Suggested change:
OLD:
On hosts with more than one IP address, this option can be used to
force the source address to be something other than the primary IP
address of the interface the probe is sent on. If "unknown" is
specified for this object it means that source address specification
was disabled.
NEW:
On hosts with more than one IP address, this option can be used in
"RequestMetadata" element to force the source address to be something
other than the primary IP address of the interface the probe is sent
on; the value "unknown" means the default address will be used.
Best regards,
Pasi
> -----Original Message-----
> From: ext Thomas Dietz [mailto:[EMAIL PROTECTED]
> Sent: 06 June, 2008 10:41
> To: Eronen Pasi (Nokia-NRC/Helsinki); Eggert Lars (Nokia-NRC/Helsinki)
> Cc: Saverio Niccolini; [EMAIL PROTECTED]; [email protected];
> [EMAIL PROTECTED]; Sandra Tartarelli; Juergen Quittek; [EMAIL PROTECTED]
> Subject: RE: Gen-ART review of
> draft-ietf-ippm-storetraceroutes-07 (-08)
>
> Dear Pasi,
>
> We just submitted a new version (10) of this draft. I hope we
> now addressed
> all you comments. Changes are:
>
> * Fixing number of ProbeResults per Measurement
> * Aligning description of draft and schema
> * Simplifying XML for InetAddress (improves readability)
> * Aligning default values with RFC4560
> * Reviewing and updating Appendix C
>
> Please review the new version another time.
>
> Thank you for your effort.
>
> Thomas
>
> --
> 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: Donnerstag, 22. Mai 2008 18:58
> > To: [EMAIL PROTECTED]; Thomas Dietz
> > Cc: Saverio Niccolini; [EMAIL PROTECTED]; [email protected];
> > [EMAIL PROTECTED]; Sandra Tartarelli; Juergen Quittek;
> [EMAIL PROTECTED]
> > Subject: RE: Gen-ART review of
> draft-ietf-ippm-storetraceroutes-07 (-
> > 08)
> >
> >
> > Going over version -09...
> >
> > I think the element nesting is still wrong: MeasurementResult should
> > contain exactly one (not 1...2550 as said in Section 5.2.1, or
> > 1...4294967295 as said in the schema) ProbeResult element.
> (Otherwise,
> > you need to describe what semantics having multiple ProbeResults
> > inside one MeasurementResult would be -- but I think this was just
> > editorial mistake.)
> >
> > In number of places, the information element description in
> Section 5
> > doesn't match the xs:documentation in the schema (earlier
> versions of
> > the draft used word-by-word identical text in both places). In some
> > cases, the differences look significant (and the newer text,
> > in the schema, is mostly the correct one).
> >
> > The description of CtlSourceAddress still has conflicting text
> > about what the element contains in MeasurementMetadata in case
> > RequestMetadata didn't request a specific source address.
> >
> > The text and schema are still inconsistent about the
> InetAddress type
> > (in text, it's a single address; in schema, it's a list of
> addresses).
> >
> > The description of what elements are optional in Section 5.1 doesn't
> > match the schema.
> >
> > Default values for CtlProbeDataSize and CtlMaxFailures don't match
> > RFC 4560.
> >
> > CtlMiscOptions should probably have either default="" or
> minOccurs="0",
> > but not both.
> >
> > Appendix C is most likely out-of-date.
> >
> > Best regards,
> > Pasi
> >
> > > -----Original Message-----
> > > From: Eggert Lars (Nokia-NRC/Helsinki)
> > > Sent: 20 May, 2008 10:54
> > > To: ext Thomas Dietz
> > > Cc: Eronen Pasi (Nokia-NRC/Helsinki); Saverio Niccolini;
> > > [EMAIL PROTECTED]; [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 the quick turnaround on the revision!
> > >
> > > Pasi, can you check if you're OK with this version?
> > >
> > > Thanks,
> > > Lars
> > >
> > >
> > >
> > > On 2008-5-20, at 10:52, ext Thomas Dietz wrote:
> > >
> > > > Dear all,
> > > >
> > > > I just submitted version 09 of the storetraceroutes
> draft. I hope
> > > > all major
> > > > issues are sorted out now. I did the following changes to the
> > draft:
> > > >
> > > > * Adjusted description of test name (because of relaxed
> uniqueness)
> > > > * Made the CtlTypes extendable as proposed by Pasi
> > > > * Added a reference for setsockopt (IEEE.1003.1G)
> > > > * Aligned ProbeResult history with RFC4560
> > > > * All Metadata elements are now required but have a default
> > > > * Adjusted the inetAddress XML types and their usage
> > > > * Aligned the _roundTripTime type with RFC4560
> > > > * Added HopAddress to store the DNS name of HopAdress
> if available
> > > > * Added a bunch of examples
> > > >
> > > > Please review this version thoroughly and I hope it fits all its
> > > > requirements now.
> > > >
> > > > Best Regards,
> > > >
> > > > Thomas
> > > >
> > > > --
> > > > 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: Lars Eggert [mailto:[EMAIL PROTECTED]
> > > >> Sent: Dienstag, 13. Mai 2008 14:08
> > > >> To: Thomas Dietz
> > > >> Cc: [EMAIL PROTECTED]; Saverio Niccolini;
> [EMAIL PROTECTED]; gen-
> > > >> [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sandra Tartarelli;
> > > Juergen Quittek;
> > > >> [EMAIL PROTECTED]
> > > >> Subject: Re: Gen-ART review of
> > > draft-ietf-ippm-storetraceroutes-07 (-
> > > >> 08)
> > > >>
> > > >> Hi,
> > > >>
> > > >> it's been two weeks since the last emails, and it's been almost
> > > >> half a
> > > >> year since this document has been pub-requested. It needs to be
> > > >> updated, and then it needs to go back to the WG for a
> last call,
> > > >> followed by another IETF last call, before it can go
> to the IESG,
> > > >> because of the magnitude of thechanges (four revisions
> since the
> > > >> WGLC).
> > > >>
> > > >> Do the authors and WG have enough energy to see this
> document to
> > > >> completion?
> > > >>
> > > >> Lars
> > > >>
> > > >> On 2008-4-29, at 18:03, ext Thomas Dietz wrote:
> > > >>
> > > >>> 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
> > > >
> > >
> > >
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
