ietf
[Top] [All Lists]

Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

2008-06-16 23:37:35
Frank Ellermann wrote:
Brian E Carpenter wrote:

  
That's my opinion; I'm not asserting that it's an IETF
consensus or that it necessarily applies to 2821bis.
    

+1

Some things I'd consider:

RFC 821 used foo.arpa and similar examples, and it won't
surprise me if the author knew precisely why this can
never have any undesirable side-effects.

As explained by John RFC 2821 switched to foo.com.  All
address harvesters looking for strings with an "@" have
found it years ago, nothing 2821bis will do can fix it.

Or the opposite effect, the RFCs listed in RFC 3092 might
have contributed to a better page rank of foo.com, maybe
the current owner has no problem with the overall effect.

Whatever 2821bis does, it cannot change the good or bad
caused by RFC 2821 and other RFCs.  Therefore the issue
is at first glance purely editorial.

*BUT* 2821bis will be one of the most important RFCs for
many years - assuming it goes "as is" to STD - and many
readers, who will take it as gospel.  They will see the
foo.com examples, and use similar constructs for their
own examples.  They won't know or read RFC 2606, and if
they get push back they can say "but 5821 also does it".

Of course I'd ignore red lights when there's no traffic,
and I just want to cross the street.  And I'd be upset
if some "authority" tells me that I shouldn't do this.
But is it really necessary to ignore red lights in the
presence of kids who have no clue what can go wrong ?
  

The issue at hand (the DISCUSS and appeal) is at odds with the AD's view,
regarding updating names used in examples versus RFC2606.

In the interests of resolving the issue while respecting both the desire 
to preserve
the text between 2821 and 2821bis, and to acknowledge that the examples used
aren't 2606-compliant and preserved only to avoid making too many changes to
a document with a long history/ancestry, what about a minor compromise by
both parties?


Here's my suggestion:

List 2606 in the informative references, and footnote the examples used 
to indicate
that they are "grandfathered" non-2606 examples.

So, in text that previously read "not-example.com", it might read 
"not-example.com [*]",
with the references section having "[*] Note - non-RFC2606 examples 
used. Please read RFC2606."

Something along those lines, should hopefully be enough to keep both 
sides happy, and resolve the DISCUSS,
and hopefully both set a suitable precedent *and* make moot the appeal.

YMMV.

Brian Dickson
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>