Terminology for Describing Internet Connectivity
RFC 4084

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

(David Kessens) Yes

Comment (2004-10-21)
No email
send info
Jorge's response on liability risk:

Date: fredag, oktober 01, 2004 09:45:45 -0400
From: "Contreras, Jorge" <Jorge.Contreras@wilmerhale.com>
To: "Harald Tveit Alvestrand (E-mail)" <harald@alvestrand.no>
Subject: FW: draft-klensin-ip-service-terms

Hi Harald,

This is the response that I gave this summer on the question raised by
Section 7 of John Klensin's ID.  Please let me know if you need more.

Best regards,

-----Original Message-----
From: Contreras, Jorge
Sent: Tuesday, July 20, 2004 11:50 AM
To: 'Harald Tveit Alvestrand'
Subject: RE: draft-klensin-ip-service-terms


This issue isn't unique to John's RFC.  In fact, the potential risk is much
greater when you are dealing with a technical (rather than a definitional)
standard that could be adopted as a regulatory requirement.  The IETF rules
were developed with this risk in mind.  This is one of the reasons that
openness and procedural checks and balances are included in the standards
process (other than the inherent improvements that they may offer to the

Thus, as long as John's I-D goes through the normal standards process, and
is subject to open discussion, debate and modification by all interested
parties, I don't see any substantial risk.


-----Original Message-----
From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, July 15, 2004 4:17 AM
To: Contreras, Jorge
Subject: draft-klensin-ip-service-terms


could you take a look at draft-klensin-ip-service-terms, defining terms
that could be used to describe IP service offerings, from a liability

I think the "interesting" aspecs are if these terms turn up in RFPs or
legal requirements, and someone whose service doesn't match the
requirements of a specific requested/required level shouts "restraint of

John put some of that into section 7 of the doc.
Draft attached.


---------- End Forwarded Message ----------

(Bert Wijnen) Yes

(Harald Alvestrand) No Objection

Comment (2004-10-28)
No email
send info
Reviewed by John Loughney, Gen-ART

His review:

Looks good, ship it.

A few nits to correct:

1) Expand ISP upon first usage.
2) Expand NAT upon first usage.
  -> note that many non-English speakers forget what ISP or NAT really
     stand for.
3) Insert blank line between additional definitions in section 4.
4) Should a rough defination of broadband be attempted?
5) Should RFC2119 be a normative reference? One must read it (or have 
   read it) to understand the meanings of MAY, SHOULD, MUST.

(Steven Bellovin) No Objection

Comment (2004-10-25)
No email
send info
The citation of RADIUS (section 4) seems odd -- that's strictly a back-end function, and isn't visible to the user.

The Web connectivity definition(section 2) should note whether or not https is provided for email access.  Similar discussions may be appropriate for things like email submission servers.

(Margaret Cullen) No Objection

(Scott Hollenbeck) No Objection

Comment (2004-10-22)
No email
send info

The text in section 7 needs to be removed or replaced.  We (the IESG) should talk about that.

(Russ Housley) No Objection

(Allison Mankin) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Alex Zinin) No Objection