Re: I-D Action:draft-klensin-rfc2821bis-10.txt

I'll say that I don't want to see 2821bis held up any more over this.  A 
better treatment of IPv6-related issues in SMTP is needed, but it should 
be done in a separate document.
And in a separate document we'll be freer to say what we think is best 
because we won't have concerns about resetting 2821bis to proposed.
(I think this indicates a flaw in our process, BTW, but we're not going 
to change the process by holding up 2821bis).
Keith

p.s. More generally, I think we've seen enough by now to realize that 
neither a hodgepodge of documents where each one modifies its 
predecessors in various ways (think RFC 821, 974, 1123, and SMTP 
extensions) , nor a monolithic document that tries to be 
all-encompassing and is completely revised every several years, is a 
good way to define a standard for a complex, evolving, and vital service 
like Internet email.


Lisa Dusseault wrote:
> On Apr 17, 2008, at 11:09 PM, Paul Smith wrote:
>
> > Keith Moore wrote:
> > > Oh, I saw that message.  I just didn't see the consensus.
> > It wasn't a consensus, it was a unilateral statement based on the fact 
> > that there wasn't a consensus.
> Given that we're revising an ambiguous document, it was a conservative 
> decision, even if it was a unilateral statement and even if the 
> consensus on something new to recommend isn't clear.
> > I think it was totally the wrong action.
> I also think arguing interminably, or otherwise failing to publish 2821 
> bis, would be the wrong action.  There are few situations where we just 
> can't get consensus in a timely manner in the IETF and have to do 
> something else, and the right thing to do as that "something else" is 
> case-dependent.
> My serious offer here is that if somebody sees a way towards consensus 
> on the implicit MX issue, please help find it or build it.  The result 
> of that consensus may not go into this document, but I will help to get 
> the consensus documented and published.
> Lisa