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.  

> 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.  

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.  

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.

> 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.

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

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

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.

 Frank

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