Subject: RE: [newtrk] web-based lists of RFCs

From: <[email-masked]>
Date: Tue, 12 Jul 2005 08:11:15 +0300

Brian,

> >>>I really think we need to be more aware of the real users of
> >>>our documents, the one's we never meet, otherwise our
> >>>documents will only be relevant to ourselves.
> >>
> >>No disagreement here, of course,. but how can we active that?
> >>Note that it's not enough to find the real users of the
> >>documents, we'd also need to find why they need the documents.
> > 
> > 
> > Of course, the original ISD proposal addressed that issue.  It
> > might be no coincidence that the issue of how users of IETF
> > standards who are not IETF insiders find out the approval and
> > relationship of documents was one of the drivers there.
> 
> No argument there. The question now seems to be whether this
> needs a formally defined document series such as the ISD proposal
> of record, or a less formal web structure. The substantive content
> would be much the same, I think.

As an original proponent of the Web structure, I can testify to its
allure, especially for us IETF nerds.  I think such a web structure
would make my IETF life easier.

However, that being said, one of the original reasons for the ISD
proposal was that other folks (SDOs, consortia, implementors) would
have something concrete they could point to when they need to 
tell what SIP, TCP, IPv6, SMTP, DNS, RADIUS etc. are. My idea was that
the ISD could be applied first to important protocols or technologies
and then see if we needed to back-fill the rest.

In absence of an ISD, I don't think that a web structure will work 
in the tough cases. IPv6 WG has done an IPv6 Node Requirements draft,
the TCPM WG is working on a TCP Roadmap.  I don't know what the current
status of SIP is, but its a fairly complex protocol.

Basically, what I had hoped for with ISDs would be that when someone
in my company came to me and said 'We've got to implement a standard
version of "SIP/RADIUS/TCP/etc." I'd be able to point to something
and have a high assurance that the result would be a robust and interoperable
implementation could be made from that reference.

John L.

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

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 12 Jul 2005 09:39:41 -0400

> would make my IETF life easier.

An up-to-date, comprehensive list would certainly be helpful.  I'm not
so sure about making it web-based; that might render it inaccessible
when off-line (except to the extent that it is implemented as a stand-
alone HTML document which can be downloaded for off-line use; i.e. if
the implementation is some collection of CGI scripts or the like, it
will be less than ideal).

The main questions are:
1. where are the lines drawn as to what constitutes a related specification?
and
2, who is going to do the work?
Format issues can wait until there is some sort of rough consensus of
those issues.

I maintain that the first question is inherently difficult.  Given the
difficulty and the "running code" of the (incomplete and to some extent
out-of-date) examples discussed, the second question is a concern; the
effort will be substantial and ongoing.  The IESG hasn't volunteered to
do the work, and some areas have no cognizant active working groups.  The
IESG practice of disbanding WGs as soon as they have produced a PS would
leave no WG to handle updates, even if WGs could be persuaded to produce
an initial ISD.  So I suspect that for some sort of) overview document (in
whatever format) to succeed will require identification of a likely group
of workers, and obtaining IESG buy-in on changes to practices and
procedures necessary to ensure viability of the needed ongoing effort to
maintain the documents.  If WGs are to be the maintainers, we should
consider what changes if any to BCP 25 and other procedures might be
warranted.

> status of SIP is, but its a fairly complex protocol.

I suspect that all of the technologies specifically mentioned are quite
complex.  Several have been discussed briefly.  Understanding SMTP, for
example, requires at least some understanding of the Internet Message
Format (what SMTP conveys) and of MIME (in particular, MIME requires
that SMTP transport not alter MIME-part headers contained in the
message body content).  It also requires understanding of DNS, of MX
RRs in particular.  As SMTP has provision for specification of IP
address literals, some understanding of IP (v4 and v6) is necessary.
I suspect that many application protocols have a similar dependence on
lower layer protocols, and that should be unsurprising.  And drawing
lines between layers is not easy, so that offers little chance for
complexity reduction by drawing lines.

> implementation could be made from that reference.

Optimist!  Given that some specifications are self-inconsistent, there
is no such assurance; robust, interoperable implementations are not
necessarily precluded, but they cannot be assured from the specifications
and errata as they currently exist, and with the current (lack of)
attention to details which affect the clarity of specifications w.r.t.
interoperability.  Lowering the quality bar for specifications and then
relying on some external (ISD) document to resolve ambiguities, deprecate
harmful parts of specifications, etc. doesn't solve the problems with
the specifications, it simply pushes the effort onto other (as yet
unspecified) shoulders (RFC 1925 "(6)").
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Jul 2005 10:50:10 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Bruce" == Bruce Lilly <[email-masked]> writes:
    Bruce> 2, who is going to do the work?

  Actually, I think that this is the only important question.
  Probably, if we had a good answer to this, we could make any system
work, including strict RFC2026.

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html