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

From: Lars Eggert <[email-masked]>
Date: Thu, 6 Sep 2007 16:15:14 +0300

Hi,

> On 2007-8-28, at 23:15, ext [email-masked] wrote:
>> 	Filename	: draft-ietf-ippm-storetraceroutes-04.txt

I have re-reviewed the -04 version and am much happier with it.  
Modulo the two small issues below, I think this is ready to ship.

(This was my AD review, which typically happens after pub-requesting,  
so as soon as this gets to me, it'll go to IETF LC.)

Lars

Section 5.2., paragraph 0:
 > 5.2.  Information Elements

   Does it make sense to have default values for the information  
elements
   at all? I mean, the data captured by the information model is the
   result of a particular traceroute measurement, which will have been
   taken with a fully specified set of parameters. So the defaults will
   never be actually used, no?

Section 3., paragraph 3:
 >    in the path).  Upon receiving a probe, the first hop host  
decreases
 >    the TTL value by one.

   Nit: Routers can decrease the TTL by more than one.

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 27 Sep 2007 17:18:44 +0300

Authors,

I haven't seen any reply to these comments yet.

Lars

On 2007-9-6, at 16:15, ext Lars Eggert wrote:
> (This was my AD review, which typically happens after pub- 
> requesting, so as soon as this gets to me, it'll go to IETF LC.)
>
> Lars
>
>

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 28 Sep 2007 07:45:02 +0200

Lars,

> I haven't seen any reply to these comments yet.

Sorry, I seem to have missed this mail, otherwise I'd asked about it
before closing the WGLC.

>>   Does it make sense to have default values for the information elements

I'd personally prefer sensible defaults for values over "undefined" or
"NaN" when creating a new instance of a measurement.  That way, I don't
have to remember that my code should change the values.  YMMV, but I
don't think it hurts to have them.

>> Section 3., paragraph 3:
>> >    in the path).  Upon receiving a probe, the first hop host decreases
>> >    the TTL value by one.
>>

Is this a big issue or can we fix this in IESG-LC?

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: Lars Eggert <[email-masked]>
Date: Fri, 28 Sep 2007 10:26:58 +0300

> don't think it hurts to have them.

If the information model captures parameters and results of a  
traceroute measurement, there should never be any undefined or  
unknown parameters. Even if the traceroute measurement used some  
default parameters of a specific traceroute *implementation*, the  
information model should contain the actual parameters used.   
Different tracerotue implementations have different defaults, so I  
don't see how the information model can have any defaults that are  
valid for all implementations.

> Is this a big issue or can we fix this in IESG-LC?

This is a nit that can be fixed with an RFC Editor Note.

Lars

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 28 Sep 2007 14:55:25 +0200

Lars, others,

> If the information model captures parameters and results of a traceroute 
> measurement, there should never be any undefined or unknown parameters. 
> Even if the traceroute measurement used some default parameters of a 
> specific traceroute *implementation*, the information model should 
> contain the actual parameters used.  Different tracerotue 
> implementations have different defaults, so I don't see how the 
> information model can have any defaults that are valid for all 
> implementations.

There are a couple of things where (at least all implementations that
I've seen) traceroute uses whatever the operating system returns.  The
default G/W is one example, if one runs traceroute on a box with two
connections, it will pick whatever the O/S picks when the program is
run.  There are more and for lots of measurements, this will be good
enough.

I agree that it should be clear from the data that the user didn't set
this parameter.  So, how about setting all elements by default to
something that is clearly "impossible"?

Henk

---

From: Lars Eggert <[email-masked]>
Date: Fri, 28 Sep 2007 16:02:35 +0300

On 2007-9-28, at 15:55, ext Henk Uijterwaal wrote:
> this parameter.

Shouldn't the data be set to the value that was the default of the  
particular traceroute implementation for that parameter?

>   So, how about setting all elements by default to

Lars

---

From: "Jeff W. Boote" <[email-masked]>
Date: Fri, 28 Sep 2007 09:29:59 -0600

>> something that is clearly "impossible"?

IMHO, the point of having a default in an information model is to show the 
values that were not 'captured' by the application doing the measurement.

Therefore the defaults should be a special value of some sort. But, there should 
be a way to determine 'error' special values from simply 'missing' special values.

'error' is probably not relevant for these particular values, but I bring up 
this issue simply because I think it is important that the normative text make 
the point that these special values do not indicate an error, but simply data 
that was not collected.

jeff

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 28 Sep 2007 17:31:31 +0200

> 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