ietf-mxcomp
[Top] [All Lists]

clarification on consensus call for compromise

2004-09-09 11:21:06

There seems to be some confusion on the proposal on table and on
the next steps which it implies.  To clarify that, it seems important
to step back a bit. The co-chairs have judged that there is no consensus
to move forward with the documents as they entered last call.  Since
the issues with documents do not relate to the syntax of the record,
the DNS-based mechanism, or the fundamental architecture (e.g.
application of these tests by an MTA), the co-chairs have focused the
next steps on how to retain the work which has garnered consensus
and move forward.  To do that, the co-chairs suggest that the existing
documents be modified so that the group creates a standard that:
describes the DNS-based mechanism, the MTA's application
of tests, and a modified syntax which is explicitly scoped.

In order to ensure that there are scopes for which there is no known
IPR encumbrance, the co-chairs propose a new document describing
a mail_from scope. The PRA scope would also be one of the scopes initially
described, as there is clearly sufficient interest in checking pra to
allow it to move forward as one among several scopes (interest being
judged both on public statements and deployed code).  An IANA registry
for additional scopes created by Standards Track RFCs would be created.

Under such a system, it would be up to the zone maintainer to determine
which scopes to provide data on.  It would be up to the MTA running
the check to determine which checks to run.  No single scope would
be mandatory to provide or check; it would simply be mandatory that
someone populating a record use a valid, registered scope.  The
existence of scopes which an MTA does not choose to check take up
packet space in the DNS response, but have no other effect.  While
the existence of at least one mandatory to implement scope would
be beneficial, the co-chairs do not see consensus emerging around
any single scope during the lifetime of this group.  In order not
to abandon this work completely, the appropriate thing to do is
to allow the fundamental mechanism move forward with the options
that have emerged.  Over time, deployment will tell us whether either
of these scopes is successful.

For a real consensus call on this proposal, new documents must
be produced which describe it in full.  Those would be based on
the existing documents and the co-chairs anticipate that they would
be closely related to the existing proposals, at least in regards to
the elements of the system for which we already have consensus.
The document authors have agreed to take on the work required to
undertake the additional work to make this new attempt to reach
overall consensus.

This is not a call for alternate suggestions, nor is it a consensus call
on the documents which have not yet been produced.  It is the
chairs' work plan for meeting this chartered goal of this working
group:

Aug 04 Submit working group document on MTA Authorization Record in DNS to PS

Once the documents have been produced, working group discussion of the
protocol engineering and deployment will proceed using the same subject
line headers as before, and we will move through that discussion to a second
last call.

-andy, co-chair of MARID