Subject: RE: [newtrk] Comments on draft-klensin-newtrk-std-repurposing-00. txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Aug 2004 19:19:23 -0700

> You question the mechanism for selection of WG chairs
> ("appointed by AD", basically), and also the chair's
> control over the method of communication. I think these
> are interesting topics, also, although you've not suggested
> any alternatives.

No, the charter of this group is to change the process.
I think that it is important to know the scale of the problem
before you start deciding how much effort to put into
getting organization of the deck chairs right.

One of the key problems is accountability. At one time the idea
of the 3 stage process was that there were separate communities 
being addressed. To get to proposed you convince the WG, to get 
to draft the developer community, to get to standard you convince
the users to use.

So if as seems likely to be the end result draft is simply
jettisoned. We seem to have lost the idea that the IETF process
should be responsive to the Internet user community.

Who gets to decide when we are done?

I would like to see a two phase process where the IESG only
has a role in the first stage. Progress in the second stage
should be decided by the user and developer communities.

Now the user community is somewhat different in the case of 
IPv6 or HTTP. And the IETF is certainly not representative of 
every Internet user community. But there is no reason why
there cannot be representatives drafted in.

NOMCON is a ridiculous process for choosing the IAB and IESG,
the whole charade is designed to eliminate accountability.
But the process could work for choosing representatives of 
the user and developer communities for 2 or 3 boards which
would meet a couple of times a year and go through a list
of outstanding specs that might be ready to advance.

Including the user communities might also have a second 
effect, they might feel a greater obligation to deploy
if they are involved in the decision of when the spec
is baked.

Reducing the role of the IESG need not reduce its influence.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Aug 2004 09:35:02 -0700

> This is a problem if we don't also make standards bundles. The 
> problem goes away with the standards bundles (even if those bundles 
> only contain one item).

The problemk goes away if we (1) make standards bundles and (2)
actually communicate having done so.

It seems somewhat pointless to discuss process unless we also 
discuss the output of that process. If you look at the 'Internet
standards' index RFCs you will see that there are in fact 
bundles of specifications listed.

Bundles have already been done, the problem is one of presentation,
not just process.

The case of RFC 2822 is an interesting one because the purpose
was to update 822. Although 2822 is not an accurate description
of reality, neither is 822.

I think that what we need here is described by two linked FSM
diagrams that track the status of (1) the standard, (2) the
documents that represent the standard.

The FSM for an individual document is simple:

WorkingGroup
	Transition Draft -> WorkingGroup
	Transition LastCall -> IESG

WorkingGroupEdits
	Transition Edit -> IESG

IESG
	Transition Reject -> WorkingGroup
	Transition Comment -> WorkingGroupEdits
	Transition Accept -> Publish

Publish
	Terminal

The FSM for a standard is linked, but separate.

Start
	Transition BOF -> WG

WG
	Transition LastCall -> IESG

IESG
	Transition Accept -> Proposed

Proposed
	Transition Accept -> Standard

Standard
	Transition BOF -> Revision
	Transition EndOfLife -> Obsolete

Revision
	Transition Accept -> Standard

Obsolete
	Terminal

[add in error states as desired]

According to this model RFC2822 would immediately superceed 822 as
soon as it is published in both the standards series and the document 
series.

The standard has a life that is independent of the documents that
describe it. A WG that is set up to revise documents does not have to go
through the same three ring circus as a completely new standard.

It may even be appropriate to have a standard begin at the 'Proposed'
status in the case that what is happening is that a defacto standard
is being handed over to the IETF for change control purposes.

For example, imagine that RSS (ATOM) had been handed over to the 
IETF for change control in 2001 or so. Instead of the standard 
diverging from the start there would have been a forum to bring
change proposals to. 

For example, consider the reworking of NNTP. The drafts that are
comming out are better than the original NNTP drafts from a very 
early stage. Does it make sense for them to start from scratch?

One of the consequences of the standards bundles proposal is that
it becomes natural for a continuing WG to become associated with
maintenance issues.

One of the big problems of the IETF is that there is no defect 
handling and management scheme (OASIS has a worse problem in this
regard). NNTP has been chewing up excessive bandwidth for a decade
but this has never caught anyone's attention. SMTP and NNTP
have both had major problems with SPAM.

The current situation is that this role tends to be taken up 
by other WGs in the area. But this creates a major conflict
of interest. The DNSEXT people have as their priority getting
DNSEXT support deployed. The MARID people have as their priority
getting MARID deployed and the advice comming in from DNSEXT
was more than a little self serving. doing it the DNSEXT way would
have involved a 5 year delay as new DNS servers were deployed.

One of the issues that this group needs to address is the extent
to which the IESG should be re-opening this type of discussion
and to what extent the WGs should be left to their own devices.

I was particularly upset by the attempt of BEEP advocates to
attempt to bludgeon other groups such as SACRED into layering
on top of BEEP as the annointed IETF way to do web services
rather than layering on top of standard web services transports
already supported in the industry. There was no reason to make
BEEP a 'MUST' requirement for SACRED, particularly since SACRED
would have mostly been used with XKMS or the WSS-* stack, neither
of which are layered on BEEP. But this was presented as the
way things would have to be for the spec to eventually be approved.

What I would like to see is the process reform allowing the IESG
sufficient time to pre-emptively address this type of question
as a policy issue rather than have various parties insinuate
that you had better accept their demands because they have more 
power in the IESG.

I would also like the IAB to play a more useful role and liase
more with other standards bodies. BEEP was dead on arrival as
far as the Web Services world was concerned for a range of
reasons, partly because the Web Services world was never part
of the WG, but mostly because the approach taken in BEEP, using
DTDs in place of XML Schema is simply obsolete as far as the Web 
Services world goes. DTDs are an SGML legacy, they are not part
of the new world of XML.

.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Aug 2004 12:19:42 -0700

> 3) RFC 4567 updates and improves RFC 4123. Nothing is done to RFC 
> 4124 because it was perfect.
> 
> 4) The IESG modifies the bundle for the Foo protocol to have two 
> elements, RFC 4124 and RFC 4567. That bundle has a text description 
> that says "This bundle used to be { 4123 && 4124 }".

I like this scheme but with the follwing observations:

1) We already have de-facto bundles SMTP, NNTP, IP, PKIX.

2) There needs to be a way to express the concept of core and optional. So
for example in the context of PKIX the cert profile is core but OCSP and
SCVP are peripheral. There may be sub-bundling involved so that OCSP is
itself a bundle.

3) There are in some cases specs that cut across bundle boundaries. For
example the MARID group specs are refinements of the SMTP protocol but they
also cause a modification to the DNS protocol. We need more than a rigid
hierarchy.

4) A new section analogous to the IANA considerations section in needed that
has a series of statements of the form 'This is a member of the SMTP bundle,
it creates records in the DNS bundle'.

4.1) In fact the new section is really a continuation of the IANA section.

4.2) Since we have a FSM here the moves possible in this section should be
capable of being machine readable.

So for example the MARID group would have the following section:

Exists: SMTP
Member: SMTP
   Create SMTP.SENDERID
   Create SMTP.PROTOCOL.OPTION.SUBMITTER
Affects: DNS
   Create DNS.RR.MARID
   Update DNS.RR.TXT

The revision to the draft would have:

Exists: SMTP.SENDERID
Member: SMTP
   Update: SMTP.SENDERID
   Update SMTP.PROTOCOL.OPTION.SUBMITTER
Affects: DNS
   Update DNS.RR.SENDERID
   Update DNS.RR.TXT

.