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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf