Note: This ballot was opened for revision 08 and is now closed.

(Scott Hollenbeck; former steering group member) Yes

(Allison Mankin; former steering group member) No Objection

This document has is pretty discursive.  It covers features, none of them surprising or particularly
hard to pull together.   

One bit of technology was promised in the intro and not actually specified, DTMF authorization.

HDD and FDD are used but not expanded.

There is an old-style IPR statement that indicates a claim was posted, but I can't see a claim 
on the page.  In RFC 3667 times, we wouldn't be able to read a draft and know there was
a disclosure for it anyway, so I wouldn't be able to ask about this, but in any event, I do wonder
where the claim is (not to mention what in here could be claim-worthy, though that's moot).

(Bert Wijnen; former steering group member) No Objection

- citation in abstract
- non-standard IPR statement
- no IANA considerations section
- RFC2119 not referenced, while such language is used
- etc

Similar comments have been made by others and there are 2 discusses
which cover my comments.

(Bill Fenner; former steering group member) No Objection

(David Kessens; former steering group member) No Objection

(Harald Alvestrand; former steering group member) (was Discuss) No Objection

Reviewed by Spencer Dawkins, Gen-ART

His comment on version -08:
This revision seems to address just about every one of my (many) comments.

(Margaret Cullen; former steering group member) No Objection

(Russ Housley; former steering group member) (was Discuss) No Objection

  This document could greatly benefit from a technical editor.  Several
  parts are quite difficult to understand.

  Please remove the reference from the Abstract and replace it with 
  "RFC 2305."

  Section 2.2 is missing a title.

  Please delete the 'Revision history' before publishing as an RFC.

(Ted Hardie; former steering group member) Abstain

A pass by a native speaker would help.  There are several places where I
found the document pretty hard to parse; here's an example from 2.1:

   For example, an MTA (Mail Transfer Agent) is set so that it puts mail
   with a different destination address in one mailbox. When the MTA
   receives broadcast mail (mail of more than one destination address),
   some kinds of MTAs copy the mail in one mailbox. Then, the offramp
   gateway uses POP to receive the mail from the MTA. As a result, the
   offramp gateway receives duplicate mail from the MTA.

I think the paragraph before this and the overall topic (dropping duplicates)
is clear enough that this isn't a DISCUSS, but the language there is a barrier
rather than an enabler to communication.  Dropping the whole paragraph
might make this section more readable, but the problem is more general.


Are the date and time format in 2.6 standardized somewhere?  If so, a reference
would be useful.  I'm assuming that they are not, and that the local system
must indicate what the format is.  I also found it odd that the syslog protocol
was not mentioned as an "existing network communication means" for this.
None of the ones which are mentioned are in the references as either normative
or informative.

Why is section 3.1 present?  It seems to say "nonstandard user authentication
systems may exist".