Re: [ippm] FW: http://tools.ietf.org/wg/ippm/draft-morton-ippm-delay-var-as-04.txt

[Al Morton <[e-mail]>]

Dan,

Just to weigh-in with my view:

I've given this paper to many people, and most do not
participate in IETF activities.  The feedback has been
entirely positive - this is a successful entry-level memo.

Section 5 performs a useful service for the reader: it condenses
comparisons from several sources (some which are not readily available)
into several pages of relevant info, and brings the comparisons
up to date where necessary. Perhaps it could move to an Appendix,
but it will disturb the flow:
intro - tasks - definitions - background - new comparisons - conclusions

Section 6 performs the analyses that support the new conclusions
in section 7.  In theory, we could just present the table in section
7.4 as the "Applicability Statement", but it would leave room for
much interpretation and confusion.  The purpose of this memo is to
put to rest as much controversy as possible, and the supporting detail
is needed to do that.

That said, I too am interested in comments of others, since
all comments up till now have asked to expand the details
included in this memo.

regards,
Al

At 06:00 AM 2/12/2008, you wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01C86D66.8009E61C"

Benoit,
 
Let me say that I am finding this discussion to happen a little bit too early, but I was answering to the challenge coming from Henk. Usually such discussions happen when the document became a work item, or even at WGLC.
 
Section 5 includes A LOT of history which seems to me not relevant and usually is not included in IETF documents. Maybe a short summary should be part of Section 6 but not all the details. In section 6 I do not see the point of 6.5 and 6.6, and have doubts about 6.8, but maybe I should read this one again to make sure that I understand the issues.
 
The issue with section 8 is that it goes into some details about measurement methods and devices, rather than metrics. It would be interested to hear the opinion of other IPPM folks.
 
Dan
 
 

_______________________________________________
ippm mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/ippm