Subject: [ipfix] AD review for: draft-ietf-ipfix-info-11.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 17 Mar 2006 17:42:11 +0100

Sorry that it took so long (if I say it 4 times, i.e.
for each doc I have reviewed, will you please forgive me).

Seems that a new rev might be in order ??

Bert

- bottom of page 8. enterpriseId -
  it speaks about "Information Element Identifier described above"
  I do not see where "above" it is described. In fact, I think the 
  Identifier is described in sect 4, no?

- In the 3 paragraphs of sect 3 and 3.1, I would insert the word "abstract"
  in from of each occurence of "data type(s)".
  Also the title of sect 3.1 probably reads better as "Abstract Data Types".

- sect 3.1.9
  "it is expected that strings will be encoded in UTF-8"
  That does not make it interoperable, does it?
  Would it not be better to say "strings MUST be encoded..."
  And I woudl add a citation and reference to RFC3629.

- sect 3.2
  s/future protocol extensions/future information model extensions/ ??

- page 16
  What are ID 211 and 212 ?? blank ?? reserved?? something else?
  I see the explanation on page 17. I'd suggest to make them RESERVED
  or OBSOLLETE or DEPRECATEd or give them some name with the note 
  that they are not part of the standard.

- section 5 1st sentence
  s/Flow attributes/Information Elements/ ??

- sections 5.1.3, 5.1.4., 5.1.5 and 5.1.6
  I worry about referential integrety when the ifIndex gets stored
  in offline/archive storage. On a reboot, many devices renumber the
  ifIndex for various interfaces. 
  Is this not a problem? I'd think it is at least something to
  mention/discuss/warn for.

- sect 5.2.3
  Is the message that contains this Information Element included in the
  count?? May want to make that clear for better interoperability.
  Same for some of the other exportXXXCounters

- sect 5.2.5
  Text says: number of flow records
  But in Units it says: flows
  So what is it?
  Same for sect 5.2.9

- sect 5.2.8
  Does the count include header octets?

- sect 5.2.12
  It is not clear/sopecific as to which bit is bit zero, bit one etc.

- Sect 5.2.3 and 5.2.5
  Is it best to speak about Mask?
  Or would speaking of (and naming it) PrefixLength be better?

- Sect 5.6.3
  I worry about the fact that there is discussion already about AS numbers 
  of 32-bit length. So are we future proof here?
  In the MIB/SMI world we have made it a 32bit unsigned, see
  InetAutonomousSystemNumber in RFC4001.

- sect 5.6.9
  How are new values of Labeltypes be added in the future?
  last line in this section, remove "and IP addresses" ??

- sect 5.8
  Just for my understanding, why do you need all 4 levels
  of granularity here (i.e. sec, milisec, microsec and nanosec)??

- sect 5.5.x
  Would it be usefull to add a line of text to explain how long
  (how many minutes, months, years) each granularity allows
  based on the underlying datatype?

- sect 5.9.11 to 5.9.14
  I wondered if it makes sense to say some thing more about
  "packet treatment". Like what sort of treatment? Any
  reference to an RFC?

- sect 5.10.2 speaks about flowInactiveTimeout while sect 5.10.3
  speaks about idle timeout. Should you have flowIdleTimeout
  instead of flowInactievTimeout for consistency?

- sect 5.10.11
  Make it clear that the value is hex 00 (0 could be read
  as decimal zero)

- sect 6, page 69
  I think I would make it MUST instead of SHOULD in 2nd 
  and 3rd para.

- sect 7 
  first para, pls add a ptr to the list of Information
  Element Identifiers that need to be recorded as the
  initially assigned values for this registry.
  I guess you need to point them to sect 4. 
  I doubt it is clear to IANA though what exactly to record
  from that section. You can check directly with iana to
  ask if things are clear or not and if not to work out
  text with them that they understand.

  I wonder if it would not be much better to have new
  Information Elements require a Standards Track action.
  I think that ensure much better review and evaluation
  and certainly ensure well-documented registrations.

  In any event, if you do do FCFS with expert review,
  then I would
  - require proper documentation to be publicly available
  - maybe setup some sort of template that MUST be filled
    out and approved to request registration.

  You speak about an Appendix B as having a schema/example
  on how to extend. It is howeer (I think) the Schema
  for the currently assigned values.

- Sect 8.
  I am pretty sure that the Security ADs will want to see
  more detail here. They probably want to understand which
  Information Elements contain sensitive data (and why it
  is sensitive) or privacy sensitive data (and why so).
  Probably similar to why they want to see that a MIB
  document lists the objects that are sensitive and
  why so and what the risks are if the data gets 
  intercepted.

- Appendix A and B
  I am a bit confused when I read as title
  "Formal Specification..." and then in the first para
  I read that it is informational and not normative.

  If it is a "fomral machine readable spec.." is it then not 
  intended as input to tools, code-generators, data-structure
  generators and such? In that case I would be very worried
  if no tthis schema but the text earlier in the document
  is normative and authoritative.
  
  Anyway, I asked an APPS AD if he could check the "formal"
  machine readable schema, but he does not recognize it as
  a schema that can be checked by any of his tools. So
  what is it? How can we (or anyone) check it for correctness?

administrative/bureaucracy/nits/spelling:

- sect 5.10.4

  "bewtween in time" in first sentence ??
  
  same in sect 5.10.5

- 3rd para in sect 1. I suspect that the ptrs to the various sections
  do not completely match with the actual content claimed to be
  in those sections. Specifically, the ptrs to 4 and 5 should probably 
  be 5 and 6 ??

- I see that you use MUST (i.e. rfc2119 type) language and
  so there MUST be a normative citation/reference to RFC2119.

- problems with references/citations.
  Note that my tool may give false warnings, so just check
  them.

  !! Missing citation for Informative reference:
  P071 L006:    [IEEE.802-11.1999]

  !! Missing citation for Informative reference:
  P071 L015:    [IEEE.802-3.2002]

  !! Missing citation for Informative reference:
  P071 L023:    [IEEE.P802-1Q.2003]

  !! Missing citation for Informative reference:
  P072 L026:    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6

  !! Missing citation for Informative reference:
  P072 L029:    [RFC2463]  Conta, A. and S. Deering, "Internet Control Message

  !! Missing citation for Informative reference:
  P072 L033:    [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,

  !! Missing citation for Informative reference:
  P072 L036:    [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,

  !! Missing citation for Informative reference:
  P072 L039:    [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group

  !! Missing citation for Informative reference:
  P072 L042:    [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,

  !! Missing citation for Informative reference:
  P072 L047:    [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol

  !! Missing citation for Informative reference:
  P072 L050:    [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,

  !! Missing citation for Informative reference:
  P073 L006:    [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and

  !! Missing citation for Informative reference:
  P073 L012:    [RFC3260]  Grossman, D., "New Terminology and Clarifications for

  !! Missing citation for Informative reference:
  P073 L015:    [RFC3667]  Bradner, S., "IETF Rights in Contributions", RFC 3667,

  !! Missing citation for Informative reference:
  P073 L018:    [RFC3668]  Bradner, S., "Intellectual Property Rights in IETF

  !! Missing citation for Informative reference:
  P073 L021:    [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/