[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I have some feedback regarding the papame framework draft of the 7th
of March (the date in the document is February 27). I'm trying to be
as constructive as possible, but since I'm not that familiar with the
internals of the Internet standards process in general and the stage
of this draft in particular, I might get it wrong sometimes (e.g. be
overly concrete for a "framework" draft). To make the discussion
easier I broke up my feedback into three parts:
1) Comments about what's in there
2) Things that I think must be put in
3) Stuff I'd like to see in this (or another) draft
This email contains 1)
As probably all drafts in this stage, this one is often too
general. For example the last paragraph of example 1 in section 1
could definitely be made more concrete.
Often the draft refers to "sampling parameters" and "sampling data"
where in fact more general phrase should be used given that the draft
permits hashing and filters also. For example the first two of the
last three bullets in the goals chapter.
The last paragraph of section 3.2 raises some issues worth
discussing. Does it mean that measurement cannot rely on things such
as destination prefix (or AS) which are probably available in the
router interface card? If so this point should be argued more
thoroughly. The "Deriving Traffic Demands for Operational IP Networks:
Methodology and Experience" has a very nice argument for separating
the routing infrastructure from the measurement part. Even though I
agree with that argument, applied strictly it would prohibit things
such as NetFlow aggregation. Do we want to do this?
In section 3.3 the export rate bullet mentions a limit on the number
of records per unit of time. It would probably be a good idea to set
the limit on the number of bytes/packets per unit of time if we can
have variable length records. (Can we?)
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.