Subject: Re: [newtrk] updating the newtrk charter

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Aug 2004 09:40:43 -0700

I don't pretend to fully understand  the problem but I am pretty sure there
is much more than one.

What is needed here is a comprehensive concordance of standards terms so
that all the requirements and advisories that pertain to a particular
specification can be readiy retrieved.

It is a trivial matter to do this if a modern document processing format is
used for the documents. Instead we rely on manual processes to do the job at
an enormous cost. Icann was hiting up the registrars for an increase in fees
to fund the rfc editor function.

If an organization wants to be taken seriously as a technology leader it had
better learn to use some technology that is less than two decades old.

 -----Original Message-----
From: 	Keith Moore [mailto:[email-masked]]
Sent:	Fri Aug 13 06:25:37 2004
To:	[email-masked]
Cc:	Keith Moore; [email-masked]
Subject:	Re: [newtrk] updating the newtrk charter

I don't think anything this specific belongs in a charter.  It seems to 
presume the solution.  We don't even really understand the problem yet.

Keith

> Harald (with general area AD hat on),
>
> I (with newtrk chair hat on) would like to add something like the
> following to the newtrk charter before last paragraph
>
>    As part of a revised standards track process, the group will also 
> explore
>    the creation of a new series of short IESG-approved IETF documents 
> to
>    describe and define individual IETF technology standards.  These 
> documents
>    will be annotated lists of documents that should be considered to be
>    included in a specific standard.  The documents should include a 
> date
>    stamp so that it is clear what the IETF considers that a particular
>    consisted of at any point in time.  The working group will also 
> consider
>    the usefulness of implementation and or interoperability registers 
> in
>    conjunction with such a document series.
>
>    The working group will also discuss the usefulness of new "cleanup"
>    procedures to reclassify existing standards track RFCs based on 
> breadth of
>    adoption (or lack of it) or the risk to the Internet of the 
> technology
>    described in the RFC.
>
> and these new milestones
>
>    Sep 04  publish ID describing new document series
>    Sep 04  publish ID describing a new RFC cleanup process
>    Apr 05  submit ID describing new document series to IESG for 
> publication
>            as a BCP RFC
>    Apr 05 submit ID describing a new RFC cleanup process to IESG for
>            publication as a BCP RFC
>
> also change the dates on the existing milestones to
>
>    dec 04 Publish initial Internet-Draft(s) describing a revised IETF
>           standards track
>    sep 05 Submit final Internet-Draft(s) describing a revised IETF 
> standards
>           track to IESG for publication as a BCP
>
> Scott
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Aug 2004 10:01:22 -0700

Hallam-Baker, Phillip wrote:

> I don't pretend to fully understand  the problem but

That didn't stop you from arguing a solution either!

> specification can be readiy retrieved.

Why are the old ones bad?

> to fund the rfc editor function.

The RFC editor spends a whole lot of timing actually attempting to make 
documents more readable, and not just through changes of terminology. 
That's a small part.  The hard part is when people use phrases like 
"comprehensive concordance of standards", requiring average folk to 
scratch their heads to interpret meaning ;-)

> better learn to use some technology that is less than two decades old.

Like what?  And again, why?

Eliot
.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 13 Aug 2004 10:11:47 -0700

At 9:40 AM -0700 8/13/04, Hallam-Baker, Phillip wrote:
>Icann was hiting up the registrars for an increase in fees

That's odd, because ICANN doesn't fund the RFC Editor function. If 
they were doing that, it would be tantamount to fraud. Can you send 
links showing them doing this?

--Paul Hoffman, Director
--VPN Consortium
.

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Aug 2004 15:15:32 -0400

Hi.

I'll let others respond, or not, to the rest of your helpful and
constructive note, but it would be useful, IMO, if you got your
facts right where they might make a difference.   Specifically,

--On Friday, 13 August, 2004 09:40 -0700 "Hallam-Baker, Phillip"
<[email-masked]> wrote:

>...
> It is a trivial matter to do this if a modern document
> processing format is used for the documents. Instead we rely
> on manual processes to do the job at an enormous cost. Icann
> was hiting up the registrars for an increase in fees to fund
> the rfc editor function.
>...

ICANN does not fund the RFC Editor function, has nothing to do
with the RFC Editor function, and no one (to my knowledge at
least) has proposed changing that.  So, whatever or whomever
ICANN is "hiting up" for an increase in fees, it isn't to "fund
the rfc editor function", whether that has anything to do with
what you consider "modern document processing formats" or not.

In addition, as the author of one of the documents that I think
Scott is trying to explicitly include in this charter change, I
suggest that if standards are to be useful as either
interoperability specifications or for procurement, it is very
important to have clear definitions of what is part of the
standard at what times.  The things that most people mean when
they make claims about "modern document processing formats"
don't help significantly with that objective and some of them,
by being a bit too "living" and hence easily changed, actually
impede it.

     john

.