ietf-mxcomp
[Top] [All Lists]

Re: clarification on consensus call for compromise

2004-09-09 14:56:58


I don't know if there was any confusion, but it appears I understood 
you perfectly and answered with negative exactly based on that correct
understanding that group is going to standartize scopes without any
hope that they will be able to be used worldwide - this is not a a way
to create a "standard".

Your calls for letting market decide if any "scope" is sucessfull also
suggests that we'll not have a standard for a while (until the market
made the decision...) As such the working group documents for each scope 
should be listed as EXPERIMENTAL while only the protocol should be listed 
as STANDARD when they are submitted to RFC editor for publication. 

That means that IANA registry should be maintained not only for STANDARD 
track RFCs related to scope but for EXPERIMENTAL ones as well - and it is 
probably best that IANA registry is setup to make such distinction, i.e.

SPF Scope    Status and description
-------------------------------------------------
MAILFROM     Authorization to use RFC2821 Mail From by SMTP clients
             as desribed by EXPERIMENTAL RFCxxxx

On Thu, 9 Sep 2004, Andrew Newton wrote:

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