results of document review

[[e-mail]]

bob and working group members:

i have finally finished my cover-to-cover read through of the documents and
prepared my review comments ... however, these comments are based, not on the
most recent set of documents, but on the previous set of documents:

	draft-ietf-snmpv2-coex-ds-03.txt
	draft-ietf-snmpv2-conf-ds-03.txt
	draft-ietf-snmpv2-intro-ds-03.txt
	draft-ietf-snmpv2-ip-ds-03.txt
	draft-ietf-snmpv2-mib-ds-03.txt
	draft-ietf-snmpv2-proto-ds-03.txt
	draft-ietf-snmpv2-smi-ds-03.txt
	draft-ietf-snmpv2-tc-ds-04.txt
	draft-ietf-snmpv2-tcp-ds-03.txt
	draft-ietf-snmpv2-tm-ds-03.txt
	draft-ietf-snmpv2-udp-ds-03.txt

overall, the documents look basically ok with a few significant
exceptions (i'm not going to bother the entire list with the
editorial/typo stuff i found in the cover-to-cover readthrough ... i'll
send that off-list)

it is my understanding that at this phase we are to be determining if the
documents reflect the consensus reached by the working group by the
deadline, i.e., September 15th and cleaning up any loose ends

i believe the documents do reflect the consensus reached by the open
process of the working group with one exception, and that exception is
noteworthy

the intro document does not reflect the consensus position reached and is
problematic in several aspects:

    1.  the internet draft added the asn.1 for the transitional 
	wrappers ... but, in response to my question about the intent
	for these documents, our chairperson confirmed that it is our
	intent, and that the consensus was, that we would push for these
	documents to go from proposed standard status to draft standard status

	this is in conflict with both iesg rules and network management
	area rules for elevating a document from proposed to draft

	the area sets an even higher standard than the iesg (if this policy
	has been reversed since mtr retired, i'm unaware of the announcement
	of the policy change) ... but we fail to meet the lower burden of
	iesg rule anyway

	the iesg rules for draft standards requires that (see
	rfc 1602, pp 14) "... at least two independent and interoperable
	implementations have been developed, and for which sufficient
	successful operational experience has been obtained ..."

	while we might or might not have at least two implementations,
	we without doubt do not have (and cannot have in a sufficiently
	timely fashion) the required deployment and operational experience
	that would indicate that the specification is mature and will be
	useful


    2.  it was my understanding that there was an agreement that the 
	transitional community-string based authentication would be called
	snmpv1.5 in response to my request to that effect ... the internet
	drafts do not reflect that agreement

the intro document can and must be revised if it is to be advanced to draft
status, and the fixes are quick and easy:

    1.  remove the new asn.1 describing the community-based-snmpv2 message
	wrapper, relocating it (as described below)

    2.  merely state that the snmpv2 document set consists of several documents
	smi, tc, proto ops, tm, etc, as listed (using the text that is there
	and has been for some time) and that these specifications
	are to be used in conjunction with an administrative framework but
	that the specification of the administrative framework(s) to be used
	in conjunction with the v2 document set is outside the scope of these
	specifications

this would complete the recommendation to remove all admin framework stuff
from the documents, and allow the 11 to go from proposed to draft without
delay

there was also a recommendation that we do the community-based wrapper
thing and we need a separate document to specify the snmpv1.5 admin
framework ... which is where the asn.1 should be relocated to ... this
document can then go forward with a recommendation that it be considered
to become a proposed standard 

we have several sets of text that could be used as 90+% of that document, and
i don't have a strong perference as to which text is used -- bert's document,
draft-various-snmpv2-adminv1.5-synthesis-01.txt, or otherwise

we must make these changes to the intro document because as it is, it violates
the current rules for the internet standards process as expressed in rfc1602

regards,
jdc