Guidelines for Optional Services for Internet Fax Gateways
draft-ietf-fax-gateway-options-08

[Ballot comment]
- 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.

[Ballot comment]
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).

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

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).

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

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).

[Ballot discuss]
This document has too many unclear sentences to go forward. Review has been forwarded to AD.

One particular nit: Section 2.4 talks about an "option selected by the user", where the "user" is the sender of the message that goes through the offramp.
No mechanism can be inferred for this selection; I think it should be "administrator".

[Ballot comment]
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.

[Ballot discuss]
Section 3 says:
  >
  > In order to strengthen security, it is desirable to save log
  > information in the Internet FAX Gateway using a database system.
  >
  Given the use of RFC 2119 language elsewhere in the document, this
  should be reworded with RECOMMENDED or deleted altogether.I understand
  how an audit log improves security.  Please explain why a database
  system is needed.  Please add a paragraph in either section 3 or 4 to
  discuss this topic if the paragraph is not deleted. 

  Section 3.1 does not provide any useful information.  What is an
  implementor to do?

  Section 4, 1st paragraph: Are any of these encryption techniques or
  authentication mechanisms mandatory to implement when the options defined
  in this document are used?

  Section 4, 1st paragraph, 1st sentence: Who are "they?"  Please replace
  with text that describes which parties MAY be authenticated.

  Section 4, 1st paragraph, 2nd sentence: This should probably be a separate
  paragraph.  Please provide pointers to the SMTP encryption techniques.  At
  a minimum, a "such as" phrase is needed.

[Ballot comment]
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".

State Changes to Reading List                                      from Wait for Writeup                                  by scoya

State Changes to Reading List                                      from Wait for Last Call to End                        by scoya

State Changes to Wait for Last Call to End                        from Last Call Issued                                  by jhargest

State Changes to Last Call Issued                                  from Last Call Requested                              by jhargest

State Changes to Last Call Requested                              from New Version Needed (WG/Author)                    by freed