Subject: Re: RFC Editor RFP Review Request

From: Bill Fenner <[email-masked]>
Date: Tue, 18 Jul 2006 17:51:08 -0700

>A contractual requirement at this level of detail seems totally
>crazy.

I'm afraid I agree.  I see this in our other kinds of process
specifications too -- we write rules for which you need to exercise
sensible judgement, and then fret about what happens when someone uses
bad judgement and try to write rules to prevent it.  While it would
be possible for a provider to win the RFC Editor contract, and fail
to provide rsync, that'd be an exercise in bad judgement since they'd
probably not get the contract when it was time to renew.

While it's possible to tie down most (I dare not say all)
loose ends in a protocol description, I can't imagine that you
can do it in a process document or contract, and think you'll
go crazy trying.

  Bill

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "todd glassey" <[email-masked]>
Date: Tue, 18 Jul 2006 18:01:21 -0700

Bill -
If RSYNC is not part of the Editor's Contract's SOW then it cannot be
considered and if someone was to lose that contract because they didn't
offer some service that was not on the SOW, the IETF and ISOC would be
looking at litigation IMHO.

But there is another issue - and that is the liability issues which the IETF
has tried to ignore but that rulings like Theofel v farey-Jones put in place
which sets the bar height.

In Theofel we find that anyone can sue for pulling a service out from under
them that costs them more than 5K in a given fiscal year. This is the type
of liability that operating an IETF site will carry with it as an official
mirror.

The same liability extends to those that are operating the IETF's mailing
lists as well as any number of other fiduciary liabilities which also need
to be
address.

Todd Glassey
----- Original Message ----- 
From: "Bill Fenner" <[email-masked]>
To: "Bob Braden" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 18, 2006 5:51 PM
Subject: Re: RFC Editor RFP Review Request

> sensible judgment, and then fret about what happens when someone uses
> bad judgment and try to write rules to prevent it.  While it would
> to provide rsync, that'd be an exercise in bad judgment since they'd

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 19 Jul 2006 03:06:10 +0200

Hi Bill,

> can do it in a process document or contract, and think you'll

Ok.  So I'm not sure what you propose here - should we not require
rsync and ftp mirroring capability, or should we ask for it, and not
specify chapter and verse regarding version etc.?  I'd certainly be
very unhappy completely abandoning the rsync capability.

	Henrik

---

From: "todd glassey" <[email-masked]>
Date: Tue, 18 Jul 2006 18:19:20 -0700

If you specify it then the spec will need a  formal SLA too.

Todd
----- Original Message ----- 
From: "Henrik Levkowetz" <[email-masked]>
To: "Bill Fenner" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Bob Braden" <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 18, 2006 6:06 PM
Subject: Re: RFC Editor RFP Review Request

---

From: Bill Fenner <[email-masked]>
Date: Tue, 18 Jul 2006 19:26:57 -0700

>very unhappy completely abandoning the rsync capability.

I think that RFCs should be available via [at least] rsync, ftp and www.
I think that a provider who provided less than what we have now [hint:
we currently have more than that] would be exercising bad judgement
and would probably lose the contract at renegotiation time - so are
we trying to protect against someone getting the contract who doesn't
actually want to provide services, or doesn't actually want the long-term
business, or is actively malicious to the IETF, or what?

  Bill

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 19 Jul 2006 05:14:00 +0200

Hi Bill

> business, or is actively malicious to the IETF, or what?

My thinking has been to protect against a temporary break of services
because "it's not in the contract" -- whether that break is months,
because of a failing of a possibly new provider to realize what we
currently have, or years, because we'll have to wait out a contract
period.

I don't think the availability of mirrorable content is less important
than the services which are currently specified in the Statement Of Work.

It may be that the level of detail specification should be less than
what it is now, overall; but with the current specification level I
felt it is a clear omission to not specify *any* access to the documents
except through a search facility.  I feel that direct ftp/http/rsync
access is actually more important than the search facility specified
in the proposed SOW, which is why I commented on this.

	Henrik

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Jul 2006 19:19:25 +0700

Date:        Wed, 19 Jul 2006 03:06:10 +0200
    From:        Henrik Levkowetz <[email-masked]>
    Message-ID:  <[email-masked]>

  | Ok.  So I'm not sure what you propose here - should we not require
  | rsync and ftp mirroring capability, or should we ask for it, and not
  | specify chapter and verse regarding version etc.?  I'd certainly be
  | very unhappy completely abandoning the rsync capability.

Today that might be true, but in 6 months, some new mechanism may have
blown rsync away completely.   What would you think then if the RFC editor
refused to provide the new mechanism, because they're required to provide
rsync, but don't have the resources to provide both?

All that should be required is that the RFCs be available to be fetched
via some mechanism - which mechanism doesn't matter, and should not be
specified (though given its longevity, mandating FTP as one possibility
wouldn't bother me).   If the mechanism(s) provided happen not to include
rsync, and you believe that rsync availability is important then you can
make them available that way (or someone else could).   And if the
version of rsync provided isn't the one you want, you, or someone, can
make them available via some other version.

Be reasonable about this stuff, don't put in any specifications that you
wouldn't have included 10 years ago, or that aren't very likely to be
just as relevant 10 years ahead of now.

After that, all that matters is service quality - the RFC editor
will need to keep responding to week by week user demands, or some other
organisation will replace them.

kre

---

From: Thomas Narten <[email-masked]>
Date: Wed, 19 Jul 2006 08:33:46 -0400

> very unhappy completely abandoning the rsync capability.

IMO, the SOW should have some wording that requires/implies that
information available via web pages must also be provided in a
mirror-friendly way. The principle is that that the info can be easily
be replicated on mirror servers using standard tools in a way that
minimizes data transfer by distinguishing which pages have changed and
which have not.

Mentioning specific tools, if needed, should be in an "e.g." clause,
to make clear they are examples but not hard requirements.

The actual details would presumably be sorted out be reasonable people
on both ends.

Thomas

---

From: Tony Hansen <[email-masked]>
Date: Wed, 19 Jul 2006 10:07:14 -0400

I use ftp all the time to access the RFCs. I use direct web URLs all the
time to access the RFCs. I *occasionally* use rfc-editor.org's web
interface. I agree with Henrik.

	Tony Hansen
	[email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 19 Jul 2006 15:21:06 +0200

Hi Thomas,

> The actual details would presumably be sorted out be reasonable people

That would work for me.

	Henrik

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 20 Jul 2006 18:44:33 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Tony Hansen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 19, 2006 4:07 PM
Subject: Re: RFC Editor RFP Review Request

> interface. I agree with Henrik.
I used to use ftp all the time to access the RFCs but then it stopped working
about two months ago and messages on this list, from others as well as me, and
to the relevant e-mail address have had no effect.

So I think that ftp MUST be in the RFP.  It is a technology that has proved its
worth and even if and when son of http comes along and provides us with a
different way of access, ftp will still have a role.

Tom Petch

---

From: John Levine <[email-masked]>
Date: 20 Jul 2006 20:09:21 -0000

>I used to use ftp all the time to access the RFCs but then it stopped
>working about two months ago and messages on this list, from others
>as well as me, and to the relevant e-mail address have had no effect.

That's strange.  It's always worked fine for me.  I just tried it two
seconds ago and FTP retrieval from ftp.isi.edu worked just fine.  I'm
using the fairly vanilla ftp client that comes with FreeBSD, with no
special switches.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.