Subject: Chris Smith comments on draft-ioag-base-00.txt

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 14 Jun 2000 15:16:38 -0400

These are comments from Chris Smith:

>-----------------------------------------------------
>
>After a quick peek, I have initially noticed the
>following items. This is not a comprehensive
>review - some of these items may not be quite
>as I have seen them, so if you find that you
>disagree, please speak up. In addition, highly
>relevant items may have been missed. Again,
>if you see such, speak up.
>
>1) Inappropriateness of level
>
>   This protocol does cover what it indicates - that
>   is
>       "the data transfer between the subsystems of
>       a distributed billing and accounting system."
>
>   However, it covers much more as well. Based on the
>   overall role of a protocol such as this, I had
>   expected an application layer protocol. This goes
>   much lower. It includes topics that I would consider
>   out of scope, including such items as
>   'time synchronization' and 'message fragmentation
>   and reassembly'.
>
>   I expected that an application level protocol
>   would be designed to be transport independent.
>
>2) Incompleteness
>
>   In spite of pushing all the way down to link level
>   messages (see (1) above) this protocol does not
>   cover any aspects of encrypting or protecting its
>   content except for a single bitflag to indicate
>   'contents are encrypted'. However, since there appears
>   to be little flexibility in the message content structure,
>   this would require a significant volume of work to
>   add.
>
>   Furthermore, this protocol appears to depend on the
>   security of the network on which it is carried. This is
>   reinforced by the statement.
>
>     "10. Security Considerations
>          Authentication and crypting will be part of
>          the next version of BASE."
>
>   Given the low level to which this protocol pushes its
>   definitions, it may prove difficult to add the above
>   features using either standardized or commonly accepted
>   security mechanisms.
>
>3) Inappropriate definitions
>
>   This protocol assigns the authority for something called
>   'license keys' to the "BASE registration office of the
>   INTERNET ONLINE AG". (The 'license keys' appear to actually
>   be identifiers, not keys in the more common cryptographic
>   sense of the word.)
>
>   I would have expected this to reside elsewhere if this is to
>   fall under IETF governance. Other identifiers are simply specified
>   within the draft, with a policy of having new identifiers "announced
>   to the BASE registration office of the IOAG". This practice strikes
>   me as both inappropriate, and potentially a cause of conflicting
>   identifiers in actual use.
>
>   The actual 'load types' as listed in this document also seem to
>   be the bare minimum. In particular, quality of service issues
>   appear to be restricted to bandwidth. Given the value of low
>   latency to some types of communication, the listed set of load
>   types will likely not be sufficient.
>
>   Finally, the specifed URL, http://base.ioag.com, is not defined
>   as of this writing. This seems to be intended either for more
>   information, or as the registration point - this is not made clear.
>
>4) Exact role of IETF/IESG not clear
>
>   I find that the following statement contributes to some confusion
>   regarding the relationships between IOAG, the IETF and the IESG.
>
>      "BASE was defined by INTERNET ONLINE AG (IOAG) as a part of the 
>       development of their BillingWare product. It is, however, not 
>       restricted to a specific product, but allows a standardized 
>       communication within a distributed system of load data generators 
>       and load data analyzers."
>
>   As I understand it, the above statement is true, whether or not
>   this is a draft or accepted as an EFC.
>   
>   A much more useful statement (although possibly beyond the scope
>   of a draft) would have indicated how passing this protocol into
>   the governance of the IESG would help or make a difference.
>
>   Several statements throughout the document suggest that (1) this
>   protocol is in use and (2) a next version is expected. If the
>   goal here is NOT to involve the IESG and IETF in the work of the
>   next version, why is this even being posted as a draft? I speak
>   only for myself, but it would not surprise me to find that the
>   next version of the specification would be far more restricted
>   in its scope. However, I would have initial concerns about the
>   roles and reactions of the various parties if an in-use 
>   proprietary protocol was to be picked up and heavily modified
>   by the IETF.
>
>In summary - it is reasonable to assume that there is a role for a 
>protocol to relay 'load data' for billing purposes. I am certain
>that I do not have sufficient background to know if this is covered
>by any existing IESG RFCs or initiatives.
>
>However, I would prefer to see a substantial amount of focus and
>trimming of this specification to better focus on its core
>requirements, and to better enable it to work within the
>larger domain of standards that may better address non-core
>requirements.
>
>------------------------------------------------------------ 
> Chris Smith                                +1.416.348.6090 
> Royal Bank                       [email-masked] 

In response to the procedural parts above, the IETF has a long history
of publishing protocols and networking documents of general interest
even if they are not under IETF control.  The main thing we should be
looking for in review is problems with the protocol that are not
mentioned in the protocol or conflicts with on-going IETF work.  It's
not a question of whether, as a working gorup, we approve of this, but
whether there are serious problems we see which are not pointed out in
the document.

Thanks,
Donald