Skip to main content

IANA Registration for Enumservice 'web' and 'ft'
draft-ietf-enum-webft-01

Yes

(Allison Mankin)

No Objection

(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
(Scott Hollenbeck)
(Ted Hardie)
(Thomas Narten)

Abstain

(Jon Peterson)

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

Allison Mankin Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2004-09-02) Unknown
Reviewed by Michael Patton, Gen-ART

Things to fix:

Body (section 2) mentions "RFC2619bis" without reference.  I believe
this is supposed to be a reference to "RFC3761 [3]".

Abstract has references.

Should be consistent between "ENUMservice" and "Enumservice".  In
RFC3761 (where it's defined) always uses the latter, except in
productions where all LC is used, while this draft uses the former,
except in the templates (which I expect it copied from RFC3761).  If
the document gets rev'd, I suggest being consistent with the existing
RFC.  On the other hand, I actually prefer the capitalization used in
this document as is, so I'm not going to argue too vociferously for
this.

Additional nit (Harald):

the HTTP and HTTPS methods seem to assume that the method that the user is going to use with the given URL is "GET". But they never say so.
Given their attempt to be unclear about what's actually being done in the Introduction, this may not need addressing.
The text that washes away responsibility:

   The services specified here are intended NOT to specify the protocol
   or even method of connection that MUST be used to achieve each
   service. Instead they define the kind of interactive behavior that an
   end user will expect, leaving the end system to decide (based on
   policies outside the remit of this specification) how to execute the
   service.
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2004-09-01) Unknown
  Please remove the references ([3]) from the Abstract.

  Section 2 says:
  >
  > The services specified here are intended NOT to specify the protocol
  > or even method of connection that MUST be used to achieve each
  > service. 
  >
  I do not understand the use of RFC 2119 language here.  It is unclear to
  me what an implementation MUST or MUST NOT do.  What would appear in an
  implementation report regarding this sentence?
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Steven Bellovin Former IESG member
No Objection
No Objection (2004-08-30) Unknown
Please cite RFC 3833 in the Security Considerations section
Ted Hardie Former IESG member
No Objection
No Objection () Unknown

                            
Thomas Narten Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
Abstain
Abstain () Unknown