Subject: [ippm] AD review: draft-ietf-ippm-spatial-composition

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jun 2010 14:26:53 +0100

Summary: ready to go, modulo a quick check regarding the IANA actions (see below)

Section 1., paragraph 0:
> 1.  Contributors

  Typically, this would be found in the Acknowledgement section. Also,
  the intro text needs to be changed ("thus far" doesn't make sense when
  this is being published.)

Section 2., paragraph 1:
>    composition, spatial and temporal.  The new composition framework

  Nit: s/new//

Section 2.1., paragraph 1:
>    One-way metrics defined in other IPPM RFCs all assume that the

  Suggest to informally cite the relevant RFCs rather than referring to
  them with the unspecific "IPPM RFCs" term.

Section 2.1., paragraph 2:
>    measurement can not be executed from the source to the destination.

  Nit: s/can not/cannot/

Section 3.1., paragraph 1:
>    For the primary IPPM metrics of Loss, Delay, and Delay Variation,

  Nit: add citations

Section 4.1.1., paragraph 13:
>    o  Type-P, as defined in [RFC2330], which includes any field that may
>       affect a packet's treatment as it traverses network

  Nit: s/traverses network/traverses the network/

Section 4.1.10., paragraph 7:
>    REQUIRES assumption of sub-path independence w.r.t. the metric being
>    defined/composed.

  REQUIRES is not an RFC2119 term.

Section 5.2.9., paragraph 2:
>    The mean may not be sufficiently robust statistic to produce a

  Nit: s/sufficiently robust statistic/a sufficiently robust statistic/

Section 6.1.9., paragraph 3:
>    Or, when traffic volumes rise due to the rapid spread of an email-
>    born worm, loss due to queue overflow in one network may help another

  Nit: s/born/borne/

Section 7.1.4., paragraph 0:
> 7.1.4.  Statistics: Mean, Variance, Skewness, Quanitle

  Nit: s/Quanitle/Quantile/

Section 8.1., paragraph 1:
>    method could be abused for denial of service attacks directed at
>    destination and/or the intervening network(s).

  Nit: s/destination/the destination/

Section 9., paragraph 0:
> 9.  IANA Considerations
>
>    Metrics defined in IETF are typically registered in the IANA IPPM
>    METRICS REGISTRY as described in initial version of the registry
>    [RFC4148].  However, areas for improvement of this registry have been
>    identified, and the registry structure has to be revisited when there
>    is consensus to do so.
>
>    Therefore, the metrics in this draft may be considered for
>    registration in the future, and no IANA Action is requested at this
>    time.

Henk's writeup said:

> There is one practical issues, see section 9.
> 
> The problem is that we defined a registry for our metrics but that it
> has seen almost no use at all.  This makes it hard to ask people to
> continue to maintain it.
> 
> There are suggestions to improve the registry to something that is
> useful, but these have to go through the entire WG process.  I don't
> think we should wait for that with this document, but rather just
> publish it and fix things if/when there is consensus on a new
> registry format.  And if the group decides to abandon the regisitry,
> then no time is wasted here either.

This is the first I hear about there being a registry issue. In any event, if there is, we will need to fix this, and I don;t want to hold this draft up either. Unfortunately, we cannot publish this and simply ignore the existing registry and its rules. The quickest way forward would be to add the missing registry entries to this draft.

Section 10., paragraph 0:
> 10.  Acknowlegements

  Nit: s/Acknowlegements/Acknowledgements/

Section 11.1., paragraph 2:
>    [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
>               "Framework for IP Performance Metrics", RFC 2330,
>               May 1998.

  Downref: Normative reference to an Informational RFC: RFC 2330. I saw
  Henk's writeup comment and will call this out during the IETF last
  call.

Section 11.1., paragraph 8:
>    [RFC5835]  Morton, A. and S. Van den Berghe, "Framework for Metric
>               Composition", RFC 5835, April 2010.

  Downref: Normative reference to an Informational RFC: RFC 5835. Did
  not see this in Henk's writeup, do we want to ask the community to OK
  this downref?

---

From: Al Morton <[email-masked]>
Date: Wed, 30 Jun 2010 10:06:57 -0400

At 09:26 AM 6/30/2010, Lars Eggert wrote:
>...
>This is the first I hear about there being a registry issue. In any 
>event, if there is, we will need to fix this, and I don;t want to 
>hold this draft up either. Unfortunately, we cannot publish this and 
>simply ignore the existing registry and its rules. The quickest way 
>forward would be to add the missing registry entries to this draft.

We discussed this among chairs and authors as Henk was preparing
the DocShep write-up.  Emile was willing to supply the entries
for the broken registry, but the rest felt that the quickest way
forward was to simply make this section a place-holder.
*If there is consensus to fix the registry*, all the work must
be re-done and included in the initial registry contents.

Another possible outcome is that the registry is withdrawn, based
on IPPM consensus that what we have is not useful, and what we could
create in the registry space with the capability to accommodate all
our metric options does not seem practical or useful, in addition
to the metric naming conventions we already use and options we already
specify.

It will certainly take several discussions over time to reach IPPM
consensus, starting now and with the session at IETF-78.

In any case, thanks for your comments Lars,
and sorry about all the stray nits left at this point.

Al

---

From: <[email-masked]>
Date: Wed, 30 Jun 2010 16:35:30 +0200

Hi 

I agree with Lars. This is what I suggested 3 weeks ago: add the metrics of the draft in the existing registry and then work peacefully on a new version of the registry. 

Regards
Emile

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Al
> Morton
> Envoyé : mercredi 30 juin 2010 16:07
> À : Lars Eggert; IETF IPPM WG
> Objet : Re: [ippm] AD review: draft-ietf-ippm-spatial-composition
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 30 Jun 2010 17:34:29 +0200

Hi,

>   not see this in Henk's writeup, do we want to ask the community to OK

That's an error in the write-up, the comment applied to both framework
documents.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
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
------------------------------------------------------------------------------

I confirm today what I denied yesterday.            Anonymous Politician.