Document: draft-ietf-btns-prob-and-applic-06
Reviewer: Ben Campbell
Review Date:  8 Jan 2008
IESG Telechat date: 10 Jan 2008

Summary: This document is almost ready for publication as an 
informational RFC. There are some nits that should be considered 
first.

Comments:

 IDNITs returns the warnings:

  Miscellaneous warnings:
   
 ---------------------------------------------------------------------
 -------

  == The copyright year in the IETF Trust Copyright Line does not 
 match the
     current year

  == Line 709 has weird spacing: '...ructure   iSCS...'

  == The document doesn't use any RFC 2119 keywords, yet seems to have 
 RFC
     2119 boilerplate text.


  Checking references for intended status: Informational
   
 ---------------------------------------------------------------------
 -------

  -- Obsolete informational reference (is this intentional?): RFC
 2409 (ref.
     '4') (Obsoleted by RFC 4306)

  -- Obsolete informational reference (is this intentional?): RFC
 2401 (ref.
     '9') (Obsoleted by RFC 4301)

  == Outdated reference: A later version (-10) exists of
     draft-ietf-hip-base-09

  == Outdated reference: A later version (-09) exists of
     draft-ietf-tcpm-tcpsecure-08

  -- Obsolete informational reference (is this intentional?): RFC 2960 
 (ref.
     '18') (Obsoleted by RFC 4960)

  == Outdated reference: A later version (-04) exists of
     draft-ietf-btns-connection-latching-03

  == Outdated reference: draft-williams-on-channel-binding has been 
 published
     as RFC 5056


 Section 1, paragraph 4:

 How do trusted authorities differ from trusted third parties? More to 
 the point, is a PKI out-of-band or pre-deployed information?

 Section 2.1.1, paragraph 2:

 "The first three, IPv4/IPv6 addresses and DNS names..."

 Do you mean three or two? (I assume that IPv4 and IPv6 addrs are 
 sufficiently similar in this context not to count as two by
 themselves.)

 Section 6, general:

 This section will rapidly become obsolete in that it refers to other 
 workgroups that one hopes will eventually finish their work and close 
 up shop, but this RFC is, well, forever. Is that appropriate for an 
 informational RFC? (Note that I am not saying that it is _not_ 
 appropriate--I don't know the answer on this one.)