Subject: [newtrk] Re: I-D ACTION:draft-ietf-newtrk-sample-isd-*

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Nov 2004 11:06:28 +0100

Looking at the two sample ISDs, here are my reactions:

1. This is not just makework. Documents like this would be
extremely helpful, both to IETF particpants whose brains
can't hold everything, and to the users of our specifications.

  - one consequence of that is they need to be duly reviewed
    consensus documents, because they may well end up being
    used in RFPs etc.

  - another possible consequence is that over time, they might
    resolve the problem of RFC brand dilution raised in
    draft-rosenberg-mankin-newtrk-rfc-00.txt. Of course, that
    would mean ISD becoming a brand of its own...

2. I think the *primary* version of an ISD should be a
fully linked HTML document, i.e. with links to all the
RFCs and other ISDs cited. It would then be easy to generate
a plain text version. The other way round is not so easy.

3. I would make ISD numbers be an extension of STD numbers,
e.g. the SMTP ISD would be ISD 10.

4. I found the recursive history in
draft-ietf-newtrk-sample-isd-stdproc-00.txt to be
a bit excessive. It would be good to find a way to
compress that.

5. To my mind, the ISD view of a standard makes it even
clearer that our 3 stage standards track is OBE.
What matters is the latest version, with back references
to the history, not PS vs DS vs STD.

Personally, I would fix this by inserting the
interoperable implementations log in the ISD,
and (as I've been advocating for a couple of years)
abolishing the difference between PS/DS/STD.

6. One possible rat hole: should we summarize IPR claims
in the ISD, or at least flag their existence?

    Brian

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 4 Nov 2004 06:50:32 -0600

I'm actually following up to both Brian and Lars-Erik.

I agree that this stuff is incredibly useful, and believe it will be 
more useful as (1) people who were not "in the middle of it" find that 
their non-IP applications have moved to IP (see VoIP for the most 
interesting examples, but there are others), and (2) people who WERE 
"in the middle of it" move on to something else that interests them, 
end their participation in the IETF (it is NOT a life sentence for any 
of us), retire, or ultimately move on to the only place where 80 
percent of e-mail is not spam (that WOULD be heaven).

I agree that we'll need to end up with versioning - this was actually 
pointed out fairly explicitly in the first draft, and JohnK has been 
saying it for a while - and that dated ISDs are sufficient.

I agree with Lars-Erik that including entire previous versions of the 
ISD as history will give us long ISDs very quickly. Don't forget that 
our success criteria for ISD is that we'll be able to generate new 
versions of ISDs a lot more frequently than we generate new STDs 
today. I guess I was assuming what Brian said explicitly - whether 
HTML or text is canonical, we'll need an HTML version that makes 
navigating this stuff a lot more trivial than searching (possibly 
semi- or non-existent) mailing lists. I THINK Lars-Erik's point could 
be met by a two-stage expansion - this is the ISD, containing 
everything you need to know about the current version of the ISD and 
pointers to previous versions, followed by a fully-expanded ISD (all 
versions) as shown in the example). I think this translates to "first 
level looks like Scott's example, second level looks like JohnK's 
example".

I'm not sure which expansion of "OBE" Brian was referring to, but I 
interpreted his statement as "three-stage standards maturity levels 
are somewhere between AWOL and SOL". Sadly, I agree. Three-stage 
maturity levels is one of those great moments where the IETF clearly 
saw a right and pure way to go, and just didn't go there in any 
meaningful way. Much like IPng vs NAT/DHCP, we can't go back (IMO). 
And trying to come up with a maturity level for an ISD looks even more 
painful, especially if we start saying things like "must be the lowest 
maturity level of an included document". Surrender the fantasy.

Let's be fairly open and clear about this. If ISDs don't replace STDs 
and RFCs as a brand, we will have failed, because of the reasons I 
mentioned earlier (clueful people retire and/or die, with their places 
taken by people who just don't have as much experience as, for 
instance, John Klensin has with "standard SMTP", or Scott Bradner has 
with the IETF Standards Process).

It seems irresponsible to introduce ISDs without noting the EXISTENCE 
of IPR claims that, we are told by IPR holders, may be relevant. 
Moving beyond this seems problematic - we certainly can't say "but 
this is obviously bogus", and it seems ambitious to even "summarize" 
IPR claims - especially if we are talking about rolling a new version 
of an ISD every time some actual or potential IPR holder makes a claim 
of varying applicability, right?

But, all in all, I think John and John have accomplished what I had 
hoped for based on IETF 60, and Scott's example helped quite a bit, 
too.

Looking forward to next week,

Spencer

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "New Track" <[email-masked]>
Sent: Thursday, November 04, 2004 4:06 AM
Subject: [newtrk] Re: I-D ACTION:draft-ietf-newtrk-sample-isd-*

.

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Nov 2004 10:26:31 -0500

Brian,

Spencer has provided several of the comments I would have made.
A few additional remarks, I hope not too redundant, below.

>     consensus documents, because they may well end up being

Yes

>     would mean ISD becoming a brand of its own...

Certainly it would have to become a brand of its own.  But I
don't think there are really shortcuts in any of these things
that would work.  If draft-rosenberg-mankin... were adopted,
those who were trying to use "RFC", or its absence, to identify
non-IETF documents would have to remember when the flag day was.
In practice, I can't imagine anyone doing that but, if they
didn't, the switchover would essentially "approve" all prior
RFCs as IETF documents.  The reality is that, if we want to make
a real change, then we need to make a new label and brand (while
I was trying to take a bit of a shortcut by re-using "STD", Bob
Braden and others were clearly right about the applicability of
this principle there too).

I am concerned about the workload to get these things out for
_all_ existing standards track (presumably including BCPs)
documents and I think we need to keep expectations in line with
reality.  For older documents, we have both sets of examples:
Scott is obviously motivated and qualified to bring the
standards process documents together.  I'm motivated, and
possibly qualified, to bring the SMTP collection together.  But,
for most of the older documents, I think we had best be prepared
to accept whatever something automated can produce, perhaps with
an appropriate disclaimer.  If we insist on perfection, we will
have nothing. 

Going forward, however, I think it would be perfectly reasonable
to tell a WG that is submitting a standards-track document that
the responsibility for generating a draft ISD (or update) that
puts their draft in context is theirs, with the IESG considering
the substantive draft and ISD simultaneously.  That would be a
step beyond "WG (or WG Chair) prepare the draft protocol action
notice", but not a huge step.   And it further shifts the
responsibility for procedural/documentation work that is
time-consuming, especially in the aggregate, away from the
responsible ADs, which I think the community has concluded is a
useful trend.

> a plain text version. The other way round is not so easy.

I think the *reference/archival* version of an ISD should be
plain text, for all the reasons we have made that decision about
RFCs for 35 years.  I don't think "primary" must equal
"reference/archival", so have no real problem with the above.
That said, I haven't been happy with generation of plain text
from HTML in many cases, and would far prefer an XML base
(similar to the xml2rfc work and building on it) that can
generate both HTML and plain ASCII text.

> e.g. the SMTP ISD would be ISD 10.

This was my initial instinct, which was why this general idea
started out some years ago as "turn STDs into documents, rather
than just having them be a list of numbers and RFC references".
But it really isn't workable: some of the STD sets are probably
not exactly the ISD combinations we want and, of course, any
document or set whose maximum maturity level is "proposed" or
"draft", or which is a BCP, doesn't have an STD number.  So, no
matter what we do, enough ISDs won't match the STD numbers that
it may not be worth the extra effort to preserve the ones we
have.  That said, I don't feel strongly about this, and it
occurs to me that we might say "any number under 100 matches an
earlier STD number, new numbers start with 100" and avoid any
real trouble.  

> a bit excessive. It would be good to find a way to

Let's discuss that next week.  This, and a few other topics,
are, IMO, really good topics for a f2f discussion, or even, if
necessary, a small food fight.

> abolishing the difference between PS/DS/STD.

Two separate things here:

* Interoperability log: As is probably obvious from most of what
I've said about process in the last several years, I think the
IESG is already overloaded and I'm deathly afraid of making it
worse, preferring a model in which anyone who proposes adding
work needs to propose to take twice that much work (in terms of
time) away.  You've suggested that these need to be consensus
documents, and, for the normative statements, I agree.  But, if
the IESG needs to review and approve an ISD each time an
interoperability (or IPR) assertion changes, we will kill the
ADs and ourselves.  So this looks either like a reference to an
external repository to me (reference is stable, repository
changes) or that we had better figure out an ISD format and
revision process that clearly identifies some material as
non-normative/non-consensus and permits updating that material
by some non-IESG-involving process.  I could see the latter with
a different model of secretariat, but it would be extremely
unwise, IMO, to do anything that binds ISDs to the admin
restructuring effort.

* Multi-level standards.  There are pieces of that about which
we agree, and pieces about which we don't.   IMO, in the extreme
cases, if we are going to become like certain other standards
bodies we know who approve specifications without implementation
or deployment experience and then consider them finished, we
might as well become them -- they are better at it than we are.
That said, I'm not convinced we need three levels in today's
world (two might be enough), some of our referencing and
succession rules are probably not finely-tuned enough, and,
certainly, the presence of ISDs could eliminate the worst bad
effects of the multiple-level process.   For example, I think
your "latest version" observation is likely to be true in most
cases, but not all: "we think this will succeed X, but aren't
sure until there are more implementations and you better conform
to X" might turn out to be the right answer in some cases.   So,
can we _please_ separate these two issues/proposals?

> in the ISD, or at least flag their existence?

See comment above about interoperability logs.  I think the same
principles apply here with the additional comment that
summarizing someone else's IPR claim feels to me like the worst
sort of lawyer-bait.

      john

.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 04 Nov 2004 08:04:44 -0800

> a plain text version. The other way round is not so easy.

Perhaps an XML grammar in the spirit of RFC 2629 would
be useful? It could be used to derive .txt, .html and
other formats.

Larry

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 4 Nov 2004 19:19:58 -0600

> be useful? It could be used to derive .txt, .html and

Yes, of course, this is exactly what I meant when *I* was typing 
"HTML", and I think it's likely that others made the same leap 
(followed by the same sickening thud!)...

Spencer 

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Nov 2004 11:10:04 +0100

> be useful? It could be used to derive .txt, .html and

Absolutely.  BTW, I think my apparent disagreement with John
Klensin can be resolved by a terminology change - the
*archival* version of an ISD should be plain text, and the
*active* version should include hyperlinks.

    Brian
.