Guidelines for Optional Services for Internet Fax Gateways
draft-ietf-fax-gateway-options-08
Yes
(Scott Hollenbeck)
No Objection
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
Abstain
Note: This ballot was opened for revision 08 and is now closed.
Scott Hollenbeck Former IESG member
Yes
Yes
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
(2004-08-19)
Unknown
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 IESG member
No Objection
No Objection
(2004-08-19)
Unknown
- 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 IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
(was Discuss)
No Objection
No Objection
(2005-02-03)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2004-08-17)
Unknown
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 IESG member
Abstain
Abstain
(2004-08-17)
Unknown
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".