Re: Last Call: draft-klensin-rfc2821bis

> Ned Freed wrote:

> > this entire exercise is focused on a move to draft with this revision

> In this case I'm a part of the rough, my focus is on "get it right"
> before the staus.  For 2822upd I'd be upset if it is no STD in 2010,
> 2821bis is different.

I completely and categorically disagree.

> > a move to draft is not the time to introduce new features.

> It's a trick to keep wild and wonderful new features out.  For the
> IPv6-fallback discussed in this thread "getting it right" is more
> important than the status.  Ideal case, 2821bis is good as is, and
> can replace the relevant parts of STD 10 in two years.

To the extent it's a trick, it's one intended to reach closure in something
less than geologic time.

> Worst case, we find that 2821bis should have no IPv6-fallback in
> two years, a 2821ter starting at PS would then take about five
> years before its successor can be at STD.

This is hopelessly optimistic. The odds are if this effort to move to draft
fails it will never happen period and we'll be stuck with even more
infrastructure reliance on proposed standard documents.

> With a modified 2821bis requiring PS now assuming again five years
> from PS to STD we'd be there 2013 instead of 2015 compared with the
> worst case, or in 2013 instead of 2010 compared with the ideal case.

> The question of the status PS / DS / STD alone IMO misses the point
> of getting it right.

And IMO this obsession on dotting every last I and crossing every last T is a
classic case of letting the best be the enemy of the good.

> > to be blunt I'm much more worried that if we delay long enough to
> > get consensus on this change and force a recycle at proposed the
> > necessary energy to move this document to draft won't be there
> > when it is possible to do so.

> No energy to fix it if necessary would be bad independent of the
> status.  And 2821bis as is fixes various things that needed to be
> fixed, whatever the outcome of the IPv6-fallback question and the
> status will be.

> IMO adding null-MX to 2821bis makes no sense technically, it is an
> IPv4 kludge, not something to be added to billions of IPv6 webcams
> or similar devices as "SMTP opt out".  OTOH a "SMTP opt in" by a
> mandatory MX for IPv6 could be okay.

I disagree with this as well, but I can live with either choice as long
as the current ambiguity gets resolved.

> > even then it has taken a huge amount of work.

> Sure, but SMTP is also important enough to deserve that much work.

You are SERIOUSLY underestimating how tired and out of sorts people are over
all of this.

> Actually it would have deserved more work from me, but when folks
> start whining about the status and not introducing new features at
> critical points this is pretty much demotivating, and I fear the
> outcome is not as good as it could have been without this "status
> first" group think.

Good. The "whining" as you call it pejoratively was intended to be demotivating
in regards to crammming new features into this document. Nice to hear it worked
to some extent. Too bad it didn't work even better.

				Ned 
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf