Re: [newtrk] IESG comments on ISD proposal

[Pekka Savola <[e-mail]>]

On Tue, 10 May 2005, Brian E Carpenter wrote:
> Specifically, concern was expressed that determining the right
> granularity (e.g. how many ISDs would be needed to cover the SIP area,
> and how many SIP RFCs would be pointed to by multiple ISDs) would be
> very hard, and would lead to complexity and confusion when updates occur.
> Rather than clarifying and simplifying the "standards action" event,
> it would get more complex.
>
> Another concern that was expressed was that, except for trivial cases
> where an ISD is probably not needed anyway, experience (e.g. RFC 1812,
> draft-ietf-ipv6-node-requirements-11.txt) suggests that ISDs are likely to
> require major effort to produce. That effort is probably justified in
> some cases (as the cited examples show) but not for every single standards
> action.

FWIW, I agree with both concerns.

> However, there was a feeling that for complex or fundamental
> technologies (e.g. TCP, SMTP, SIP, IPSEC) there would be a clear benefit
> to the community to have documents of some kind that give appropriate
> guidance to implementers and operators.

Agreed.  Add "DNS" to the mix.  From my perspective, it's a protocol 
mess which most requires a roadmap or a "minimal implementation 
requirements" document; there's just too many documents out there to 
understand, and just too many things an imlementer can do wrong.

However, I'm aware only of one WG which has been chartered to produce 
such documents.  So the question is, doesn't the IESG see the need for 
roadmaps (or similar documents) as the WGs aren't chartered to produce 
them ?

> The first approach is to treat the ISDs as a light-weight replacement
> for the three-level standards track.  The goal would be to make ISDs
> very simple; minimize text in the document and make an ISD little more
> than a collection of links and metadata. This would, in effect, give
> IETF blessing to the realities that the Internet runs mainly on
> Proposed Standards and that the STD series has failed as a
> citation series.

This could work.  I guess the benefit of this approach would be to 
document specification problems (which are too extensive for 
RFC-editor errata) and solutions, without having to (immediately) 
crank up a heavier process for revising the spec?

However, while revising the ISD might be a bit simpler, I guess it 
would require at least some form of IESG approval, so we'd mainly 
optimize away the RFC-editor publication and keep the modifications 
(the text the IESG needs to read) small.

> The second approach would be to create some sort of document series 
> for roadmap documents.  The ISDs would focus on describing the 
> documents that compose a standard and their interrelations.  These 
> ISDs would be fairly complicated to write--at least as complicated 
> as existing roadmap documents.  We do not believe that if ISDs are 
> going to be roadmaps their approval should be linked to 
> standards-action document approval. Also, we do not believe that if 
> ISDs are roadmaps they should be required for all technologies; 
> instead they should be used when appropriate. (This is orthogonal to 
> the three-level standards track; that could be simplified 
> independently, as implied by the newtrk charter.)

Agree.

> We do not believe ISDs can fill both possible roles.  We believe the
> current specification does not clearly state a goal and we believe
> that the lack of goal introduces significant ambiguity into the
> proposal.

Agree.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html