Subject: RE: [newtrk] some questions about WGSs

From: <[email-masked]>
Date: Wed, 24 Mar 2004 18:22:55 +0200

Kurt,

> To me, this whole WGS idea is something which WG chairs could
> today implement without any formalization.  They can simply
> by e-mail or by external WG website or other means communicate
> to the WG which I-Ds are ready for early implementation.  I
> think there is real danger in attaching any formal status to
> such communication as it will further weaken the "a work in
> progress" nature of an Internet-Draft.

How do the chairs communicate this information outside of the WG?
Not everyone who is interested in the output of a WG is on the
WG.  Usually, some vendor implements a protocol & sells it to
a customer.  If the protocol is still a draft, how does the customer
know what version of the draft is stable, even just for a test bed?
This becomes more critical for protocols that take 2 or more years
to get to RFC status.  I'm sure Spencer can pipe in with some
real-life examples of this.

John

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 24 Mar 2004 09:59:42 -0800

>How do the chairs communicate this information outside of the WG?

They can use the same means as I noted above.

>WG.

The chair need not restrict his e-mail to the WG list, and
certainly the WG's external website is not restricted to
those on the WG list.

>Usually, some vendor implements a protocol & sells it to

No draft is stable (even those in the RFC Editor queue are subject
to change (or can be returned for further work).

>to get to RFC status.

Which is actually pretty quick all considering.

BTW, how do individuals produce WGS?

Kurt 

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 25 Mar 2004 06:55:25 -0600

From: <[email-masked]>
Sent: Wednesday, March 24, 2004 10:22 AM

> real-life examples of this.

Just as background here, and I'm speaking only for myself - my "IETF
sponsor" makes probe-based network monitor equipment, and we add
support for IETF protocols when we have customer requests for them (no
surprise there), so it's not unusual for us to support (in one case
that came up yesterday) versions 2, 3, 5, and 7 of the same draft.

No problem for us - we don't transmit anything, right? we may not
decode version 4 correctly, but we won't break anything - but the two
things I can't get out of my head are:

- we don't get requests to support a specific ID version unless
someone is deploying a product that uses that specific version in a
live network, and

- it's possible that someone worried about compatibility between
versions 2, 3, 5, and 7 of this draft, but I kind of doubt it.

We prefer to implement RFCs, but this particular protocol had its
first draft in November 2000. We saw its first deployment (version 2)
sometime after March 2001, and other deployed versions after July
2001, May 2002, and January 2003, so waiting for an RFC wasn't
realistic for the vendors who were shipping network products we
monitor. So, we followed the network element vendors, so our customers
could monitor their networks.

To be very clear - we don't mind supporting multiple variants of a
draft. We can charge for custom development, and requiring a huge code
base for protocol support is a barrier to entry for our competitors.
So please don't hear my note as "we don't want to develop these
variants".

We've been talking about Mobile IPv6, but this one's a little scarier
to me, because people don't ask us for probe support protocols in
their labs - they use network protocol analyzers there. They ask us to
support protocols they deployed throughout their production networks.
We (the IETF, and my IETF sponsor) recommend against that, but if it
takes four years to get to the first stable RFC, we don't really have
anything to offer as an alternative.

Maybe WGS would be ignored - that's why I'd like to get some
experience with it, before we write it into the next version of 2026,
because we don't rev our standards process often - but I'd like to
have something to offer as an alternative. Other alternatives are, of
course, possible.

Spencer

.