Subject: RE: [ippm] AD review: draft-ietf-ippm-storetraceroutes-03

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 19 Nov 2007 12:44:54 +0100

Dear all,

I finally found time to get to the points Lars raised.
I have submitted the version -06 right now.

Issues addressed:

-fixed- there was one nit that was fixed (TTL decrease by more than one is possible)

-fixed- the discussion about "default values":

basically the default values were there for configuration information elements
and they were enforced also at XML level. Now we discussed internally and it was
going to be cumbersome to add "impossible number" as Henk suggested. Since such
configuration information elements are anyway optional at XML level we decided to
remove the enforcement from the XML schema and to have such values absent if the
user did not set them. The values are going to be specified by the specific
implementation (whatever the default is).

Thus:
   = Information element is "absent" from XML data if user does not set it
   = If user sets it, that value
   = If not, whatever the default is for the implementation

Thus I added in the -06 version the following text:
"The default values are reported (where applicable)
in the configuration information elements as reference to BCP
recommendations and are not enforced in the data model (e.g.  XML
schema).  Configuration information elements with default values are
anyway optional elements and are going to be absent in the XML data
if the user did not set such parameter whereas they are going to be
set by the specific implementation according to specific defaults
that are not common among different versions of the traceroute tool."

Moreover, I left the default values indication in section 5.2. and removed
the enforcement from XML schema.

I hope this covers the remaining issues that were raised by Lars and over the mailing list.

Cheers,
Saverio

============================================================
Dr. Saverio Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

> -----Original Message-----
> From: Henk Uijterwaal [mailto:[email-masked]] 
> Sent: Friday, September 28, 2007 5:32 PM
> To: Lars Eggert
> Cc: IETF IPPM WG
> Subject: Re: [ippm] AD review: draft-ietf-ippm-storetraceroutes-03
> 
> Lars Eggert wrote:
> > On 2007-9-28, at 15:55, ext Henk Uijterwaal wrote:
> >> I agree that it should be clear from the data that the user didn't 
> >> set this parameter.
> > 
> > Shouldn't the data be set to the value that was the default of the 
> > particular traceroute implementation for that parameter?
> 
> If the parameter is there, yes, I'd prefer that (rather than 
> having to look up what it is for this implementation).  So:
> 
>   = Default value is "impossible number" for a record.
>   = If user sets it, that value
>   = If not, whatever the default is for the implementation
> 
> 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
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ippm
> 

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Nov 2007 11:54:32 +0200

Hi,

thanks for updating the document.

>   = If not, whatever the default is for the implementation

I don't quite get this. The first and last line seem to talk about the  
same case (user did not set a parameter) but are conflicting.

Taking a step back, though, I thought the resolution was to not have  
defaults in the data model or the XML, and instead record the value  
that the given traceroute run used for each parameter.

How each traceroute parameter for the given run got set, i.e., wether  
the user specified it or it happened to be the default of the  
traceroute implementation, seems to be irrelevant, no?

> the enforcement from XML schema.

Lars

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 20 Nov 2007 12:16:31 +0100

Hi,

> defaults in the data model or the XML, and instead record the value that 
> the given traceroute run used for each parameter.

Correct, so it should be:

   = If the user sets it, that value
   = If not, the default for the implementation

This leaves one case: the implementation doesn't use that parameter.  The
idea of using an impossible value would work there as would "don't include
it".  In both cases, whoever uses the result, will have to check this.

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

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 20 Nov 2007 20:02:55 +0100

Hi, 
  
> This leaves one case: the implementation doesn't use that 
> parameter.  The idea of using an impossible value would work 
> there as would "don't include it".  In both cases, whoever 
> uses the result, will have to check this.

Now the XML data model supports exactly what Henk writes.

To avoid confusion let me describe it better:

Configuration metadata:
If the user sets the parameter then it appears in the portion of the
XML file related to the configuration (Request element of type _Metadata),
otherwise the parameter will not appear there.
This is better than "impossible value", I personally think.

Measurement data:
in the portion of the XML file related to the measurement metadata
(MeasurementMetadata element of type _Metadata) it will appear the
actual value that the user set if the user set it, otherwise the default
for that particular implementation (that can not be enforced by the
XML file since there are no default common to all implementation, maybe
only the port traceroute use and if you want I can put this default number back,
anyway I removed all deafult enforcements from the XML schema).

Hope this clarifies the issue :-).

Cheers,
Saverio

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Nov 2007 12:22:42 +0200

> anyway I removed all deafult enforcements from the XML schema).

OK, I think this resolves it for the XML.

I still don't get why the info model has defaults, though. I may not  
have had enough coffee this morning, but I can't quite parse this new  
text in -06 that attempts to explain it, either:

> schema).

This seems to say that the defaults in the info model are based on  
some BCP? Which BCP? Can you cite it here, please?

>  Configuration information elements with default values are

OK, but if they are optional and will not be in the XML if the user  
didn't specify them, why does the info model have them? Shouldn't they  
simply be removed?

Thanks for your patience, by the way. I appreciate you taking the time  
to walk me through this.

Lars

---

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 21 Nov 2007 20:00:32 +0100

Lars, all,

thanks for taking time to look into this.

I must admit this is a weak point of the draft (as you noticed).
The default values in the info model are not really showing a consistent
indication... Maybe it is worth removing at least some of them for which
the study is not complete.

Summary (also have a look at Appendix A.  Traceroute Default Configuration
Parameters):

-- CtlBypassRouteTable --> false
this is a real deafult value, if the user does not set it, then the
normal routing is followed

-- CtlProbeDataSize --> 0
actually browsing a bit it seems to be 38 the default reported in some
man pages in the web

-- CtlTimeOut --> 3
one implementation that we tried out had 3 as default, two implementations
had 5 and another one had 4 as default, it seems to be system dependent

-- CtlProbesPerHop --> 3
all implementation tested and found on the web had this as default

-- CtlPort --> 33434
it is the IANA assigned port, 33434, used as default by almost all implementations

-- CtlMaxTtl --> 30
on FreeBSD this varies, otherwise it is always 30 in the test we have been doing

-- CtlDSField --> 0
all implementation tested and found on the web had this as default

-- CtlIfIndex --> 0
no real deafult is available

-- CtlMaxFailures --> 5
no real default value found

-- CtlDontFragment --> false
this is a real deafult value, if the user does not set it, then the don't
fragment bit is not set

-- CtlInitialTtl --> 1
all implementation tested and found on the web had this as default

-- CtlType --> UDP
Actually some implementations use ICMP Echos instead of UDP datagrams but
UDP is more common

I know that browsing on the web does not mean we have real defaults, that is why I called them BCPs.

What is your suggestion, how should we handle this?

Cheers,
Saverio

> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Wednesday, November 21, 2007 11:23 AM
> To: Saverio Niccolini
> Cc: Henk Uijterwaal; IETF IPPM WG
> > XML file related to the configuration (Request element of type 
> > _Metadata), otherwise the parameter will not appear there.
> > actual value that the user set if the user set it, otherwise the 
> > default for that particular implementation (that can not be 
> enforced 
> > by the XML file since there are no default common to all 
> > implementation, maybe only the port traceroute use and if 
> you want I 
> > can put this default number back, anyway I removed all deafult 
> > enforcements from the XML schema).
> 
> I still don't get why the info model has defaults, though. I 
> may not have had enough coffee this morning, but I can't 
> quite parse this new text in -06 that attempts to explain it, either:
> 
> > "The default values are reported (where applicable) in the 
> > configuration information elements as reference to BCP 
> recommendations 
> > and are not enforced in the data model (e.g.  XML schema).
> 
> This seems to say that the defaults in the info model are 
> based on some BCP? Which BCP? Can you cite it here, please?
> 
> >  Configuration information elements with default values are anyway 
> > optional elements and are going to be absent in the XML data if the 
> > user did not set such parameter whereas they are going to be set by 
> > the specific implementation according to specific defaults that are 
> > not common among different versions of the traceroute tool."
> 
> OK, but if they are optional and will not be in the XML if 
> the user didn't specify them, why does the info model have 
> them? Shouldn't they simply be removed?
> 
> Thanks for your patience, by the way. I appreciate you taking 
> the time to walk me through this.
> 
> Lars
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Nov 2007 15:26:29 +0200

Hi,

> the study is not complete.

so I understand now that the defaults in the info model are based on  
what most traceroute implementations seem to use as a default.

> that is why I called them BCPs.

Ah - I was confused by the term BCP, because I thought you were  
refering to a BCP-level RFC that would defined them. That's not the  
case then.

> What is your suggestion, how should we handle this?

Why does the info model even *have* defaults?

For a given measurement, you'd always store what the traceroute  
implementation that was used for the measurement used for all  
parameters (i.e., either the default parameters of that traceroute  
implementation, or what the user that ran the tool chose as overrides  
for that run for some of those implementation defaults).

If this is the case, I'm unclear why the info model even includes  
defaults - can they simply be removed?

(Or am I missing something fundamental here?)

Thanks,
Lars

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 22 Nov 2007 14:44:31 +0100

I am fine with removing them...

Saverio

> Sent: Thursday, November 22, 2007 2:26 PM
> To: Saverio Niccolini
> > The default values in the info model are not really showing a 
> > consistent indication... Maybe it is worth removing at 
> least some of 
> > them for which the study is not complete.
> 
> so I understand now that the defaults in the info model are 
> based on what most traceroute implementations seem to use as 
> a default.
> 
> > I know that browsing on the web does not mean we have real 
> defaults, 
> > that is why I called them BCPs.
> 
> Ah - I was confused by the term BCP, because I thought you 
> were refering to a BCP-level RFC that would defined them. 
> That's not the case then.
> 
> For a given measurement, you'd always store what the 
> traceroute implementation that was used for the measurement 
> used for all parameters (i.e., either the default parameters 
> of that traceroute implementation, or what the user that ran 
> the tool chose as overrides for that run for some of those 
> implementation defaults).
> 
> If this is the case, I'm unclear why the info model even 
> includes defaults - can they simply be removed?
>