Subject: [newtrk] Next steps on ISD?

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 4 Apr 2005 06:45:30 -0500

The list has been pretty quiet for a couple of weeks - what do we need 
to do, in order to have ISDs nailed down before Paris?

Spencer 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Apr 2005 16:50:28 +0200

My personal feeling is that there have been enough requests for
clarification that the draft needs to be revised accordingly.

Also, the weak spot seems to be: where will the effort come from
to develop ISDs retrospectively? Where will the effort come from
to maintain ISDs after the relevant WG closes down? Unless we can
answer those questions convincingly, it's hard to see how this will
reach takeoff speed.

   Brian (speaking for himself)

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 4 Apr 2005 20:47:40 -0500

Hi, Brian,

> to develop ISDs retrospectively?

Sigh.

One common assumption is that when one finds oneself deep in a hole, 
the first step should be to stop digging.

On retrospective ISDs - it seems to me that one of two conditions 
would be true for any STD or proto-STD: either it's painful enough to 
decode that it's worth producing an ISD for, or it's not. If it's not 
painful enough to justify work, why not leave it lying in a pool of 
disconnected RFCs and errata?

Speaking only for myself, it seems to me that a quick look at
http://www.ietf.org/html.charters/sip-charter.html
http://www.ietf.org/html.charters/simple-charter.html
http://www.ietf.org/html.charters/sipping-charter.html
http://www.ietf.org/html.charters/sipping-charter.html
http://www.ietf.org/html.charters/enum-charter.html
would give me a pretty good idea where I am headed without ISDs.

Your mileage may vary (if you're an NFSv4 type, 
http://www.ietf.org/html.charters/nfsv4-charter.html looks a lot less 
scary than my life is going to). But I'm thinking I'm not the only 
person who is looking at, potentially, a few dozen specifications of 
various vintages, maturity levels, and interdependencies.

Bill Fenner posted a pointer to 
http://rtg.ietf.org/~fenner/ietf/deps/index.cgi on NEWTRK a while 
back. If you haven't at least tried it on some of your favorite 
working groups (since the working group name works as a substring 
match), you're missing a treat.

Margaret has pointed out that ISDs won't write themselves, and the 
IESG can't reasonably be expected to write them, and I agree.

Margaret has pointed out that we have some piles of RFCs that don't 
clump into obvious ISDs (using examples from the IPv6 community), and 
I believe her.

I would still like to take a shot at doing some ISDs for work that is 
still underway, while there is still enough energy to, possibly, 
produce ISDs.

> Where will the effort come from

We deliberately shut down the communities that would be most likely to 
maintain ISDs, of course... ("self-inflicted wound, move foot before 
pulling trigger")

I can't promise you that shutting down relevant WGs is the WRONG thing 
to do (the cure might be worse than the disease), but it IS worth 
noting that Harald suggested maintenance teams not quite two years ago 
on the Solutions mailing list, and that idea probably makes at least 
as much sense today as it did then.

Spencer 

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Apr 2005 10:24:42 +0200

Spencer, I think my point is that without a solid proposal for maintenance
teams, the ISD proposal is incomplete. I really would like the IESG to get
a complete proposal, otherwise all these questions will be asked in the
form of DISCUSS comments during IESG review.

    Brian

Spencer Dawkins wrote:
> One common assumption is that when one finds oneself deep in a hole, the 
> first step should be to stop digging.
> 
> On retrospective ISDs - it seems to me that one of two conditions would 
> be true for any STD or proto-STD: either it's painful enough to decode 
> that it's worth producing an ISD for, or it's not. If it's not painful 
> enough to justify work, why not leave it lying in a pool of disconnected 
> RFCs and errata?
> 
> http://rtg.ietf.org/~fenner/ietf/deps/index.cgi on NEWTRK a while back. 
> If you haven't at least tried it on some of your favorite working groups 
> (since the working group name works as a substring match), you're 
> missing a treat.
> 
> Margaret has pointed out that ISDs won't write themselves, and the IESG 
> can't reasonably be expected to write them, and I agree.
> 
> clump into obvious ISDs (using examples from the IPv6 community), and I 
> believe her.
> 
> still underway, while there is still enough energy to, possibly, produce 
> ISDs.
> 
> to do (the cure might be worse than the disease), but it IS worth noting 
> that Harald suggested maintenance teams not quite two years ago on the 
> Solutions mailing list, and that idea probably makes at least as much 
> sense today as it did then.
> 
> Spencer
> 
> .

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 5 Apr 2005 06:40:36 -0500

Hi, Brian, thanks for the feedback.

OK, this is actually a pointer to progress (need a "solid proposal for 
maintenance teams").

- I can work on this - who else would like to?

- I don't see an obvious reason why a proposal for maintenance teams 
needs to be part of the draft that defines ISDs (I agree with "part of 
a complete proposal", but don't know whether it needs to be "all in a 
single draft") - if anyone sees obvious reasons, please tell me what 
they are.

The other issues raised are (1) ISD XML Schema (not DTD - did we 
decide this?) and (2) how to deal with the current standards-track 
RFCs that aren't in an ISD.

We've had some handwaving discussions about how to bootstrap (I 
remember "existing STD is assigned an ISD identifier" and "default is 
one ISD for each standards-track document, if you need to clump them 
or add descriptive texts, do that work when you need to", and I'm sure 
there were others mentioned).

Do we think that all standards-track specifications need to appear in 
(at least) one ISD?

Spencer

>> One common assumption is that when one finds oneself deep in a 
>> hole, the first step should be to stop digging.
>>
>> would be true for any STD or proto-STD: either it's painful enough 
>> to decode that it's worth producing an ISD for, or it's not. If 
>> it's not painful enough to justify work, why not leave it lying in 
>> a pool of disconnected RFCs and errata?
>>
>> http://www.ietf.org/html.charters/nfsv4-charter.html looks a lot 
>> less scary than my life is going to). But I'm thinking I'm not the 
>> only person who is looking at, potentially, a few dozen 
>> specifications of various vintages, maturity levels, and 
>> interdependencies.
>>
>> clump into obvious ISDs (using examples from the IPv6 community), 
>> and I believe her.
>>
>> I would still like to take a shot at doing some ISDs for work that 
>> is still underway, while there is still enough energy to, possibly, 
>> produce ISDs.
>>
>> We deliberately shut down the communities that would be most likely 
>> to maintain ISDs, of course... ("self-inflicted wound, move foot 
>> before pulling trigger")
>>
>> I can't promise you that shutting down relevant WGs is the WRONG 
>> thing to do (the cure might be worse than the disease), but it IS 
>> worth noting that Harald suggested maintenance teams not quite two 
>> years ago on the Solutions mailing list, and that idea probably 
>> makes at least as much sense today as it did then.
>>
>> Spencer
>>
>> .
>> newtrk 
>> resources:_____________________________________________________
>> mhonarc archive: 
>> http://darkwing.uoregon.edu/~llynch/newtrk/index.html
>>
>
> .
> newtrk 
> resources:_____________________________________________________
> mhonarc archive: 
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html
> 

.