Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (-08)

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 6 Jun 2008 09:40:32 +0200

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-masked]
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-masked] [mailto:[email-masked]]
> Sent: Donnerstag, 22. Mai 2008 18:58
> To: [email-masked]; Thomas Dietz
> Cc: Saverio Niccolini; [email-masked]; [email-masked];
> [email-masked]; Sandra Tartarelli; Juergen Quittek; [email-masked]
> 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-masked]; [email-masked]; [email-masked]; Sandra
> > Tartarelli; Juergen Quittek; [email-masked]
> > 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-masked]
> > > 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-masked]]
> > >> Sent: Dienstag, 13. Mai 2008 14:08
> > >> To: Thomas Dietz
> > >> Cc: [email-masked]; Saverio Niccolini; [email-masked]; gen-
> > >> [email-masked]; [email-masked]; Sandra Tartarelli;
> > Juergen Quittek;
> > >> [email-masked]
> > >> 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-masked]
> > >>> 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-masked] [mailto:[email-masked]]
> > >>>> Sent: Montag, 14. April 2008 11:57
> > >>>> To: Thomas Dietz; Saverio Niccolini; [email-masked];
> > >>>> [email-masked]
> > >>>> Cc: [email-masked]; [email-masked]; Sandra Tartarelli;
> > >>>> Juergen
> > >>>> Quittek; [email-masked]
> > >>>> 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-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 10 Jun 2008 11:26:26 +0200

Hi all,

Can the Gen art team confirm (or deny) that they are happy with this
version?

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Tue, 10 Jun 2008 13:00:43 +0300

Dear Thomas,

Thanks for updating the draft. This version addresses all my
comments except one:

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

> From: ext Thomas Dietz [mailto:[email-masked]] 
> Sent: 06 June, 2008 10:41
> To: Eronen Pasi (Nokia-NRC/Helsinki); Eggert Lars (Nokia-NRC/Helsinki)

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 11 Jun 2008 11:10:51 +0200

Hi all,

I think Pasi's last comment is correct.  I don't think we need a
new version just for this change though.   In order to wrap this up:

  1. Thomas et al: can you please summarize the main changes made to
     document on the IPPM list.

  2. We can then start a short second WGLC.

  3. Pasi's comment (and whatever else the WGLC brings up) can be
     included just before we send it to the IESG.

Does this sound reasonable, I'd like to get this document done before
Dublin.

Henk

---

From: Lars Eggert <[email-masked]>
Date: Wed, 11 Jun 2008 11:13:49 +0200

> 2. We can then start a short second WGLC.
...
> Does this sound reasonable, I'd like to get this document done before

Sounds reasonable, but depending on the magnitude of the changes,  
another IETF Last Call may also be required, which may delay IESG  
discussion of this document until after Dublin.

Lars

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 11 Jun 2008 11:23:19 +0200

> discussion of this document until after Dublin.

That's no problem for me.  It is just that I'll be away for a couple
of weeks right after Dublin (to a place without Internet access), so
I like to get everything done from my side before that.

Henk

---

From: "Thomas Dietz" <[email-masked]>
Date: Wed, 11 Jun 2008 12:19:01 +0200

Dear Henk,

I fully agree. I will put up a summary and send it to the list.

Best Regards,

Thomas

> From: Henk Uijterwaal [mailto:[email-masked]]
> Sent: Mittwoch, 11. Juni 2008 11:11
> To: [email-masked]
> Cc: Thomas Dietz; [email-masked]; Saverio Niccolini; gen-
> [email-masked]; [email-masked]; Sandra Tartarelli; Juergen Quittek;
> [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (-
> 08)
> 
> Hi all,
>