I fully agree with Debbie here.
Human experience teaches us that examples will
be used, over time. Foo.com is a commercial site. If the IETF uses
foo.com in email examples,
it is reasonable to assume that foo.com will get unwanted traffic
because of that. I think that
the IETF should not put itself in the position of causing avoidable
pain to others, even if the likelihood of serious harm is small. Since
there is a remedy, and it could be adopted readily, I think that the
discuss was reasonable and do not support the appeal.
Regards
Marshall
On Jun 17, 2008, at 10:50 AM, Debbie Garside wrote:
Not being a expert on this but having briefly read the documents in
question, I agree with Brian. This is not editorial. I would also
add that
to go against an IETF BCP on the grounds of "well we have done so
already
historically" does not make an argument for continuing to do so;
errors
should be corrected when found, not endorsed. If we are to pick and
choose
which RFC's/BCP's we will take notice of what is the point of
standardization? On the face of things, and with my little
knowledge, I
would say that the person within the IESG who has invoked the
DISCUSS is
quite correct.
Feel free to try to change my mind.
Best regards
Debbie Garside
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Brian E Carpenter
Sent: 16 June 2008 22:42
To: Pete Resnick
Cc: John C Klensin; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: Appeal against IESG blocking DISCUSS on
draft-klensin-rfc2821bis
Pete (and Dave Crocker),
On 2008-06-17 03:20, Pete Resnick wrote:
On 6/16/08 at 10:00 AM +1200, Brian E Carpenter wrote:
I think one can make a case that in some documents, use of
non-RFC2606 names as examples is a purely stylistic
matter, and that
in others, it would potentially cause technical confusion.
Please make that case if you would, because the example you give:
In the evaluation record for what became RFC4343
(https://datatracker.ietf.org/idtracker/ballot/1612/) we find:
"Editorial issues:
- the document uses a number of non-example.com/192.0.2.0
addresses/names, but in this case this seems justifiable"
In other words this *was* a judgement call.
...quite specifically said it was an "Editorial issue".
Please explain
the circumstance in which it would not be an editorial issue.
Well, I've seen *many* cases of disagreement whether a
particular issue was editorial or substantative, so I
wouldn't claim that there is any absolute standard here. And
I've been trying not to comment on the specific issue of
2821bis, because I have not reviewed it in detail and make no
claim to expertise. Nor am I commenting on whether the
specific DISCUSS comments in this case are reasonable or not
and whether they are well-formulated or not.
If a real domain name, or a real IP address, or a real IP
prefix, is used as an example in code, pseudo-code, or in the
description of a configuration mechanism, there's a good
chance that it will end up in an actual implementation or in
an actual configuration file one day (far from the IETF). In
my opinion that is a source of technical confusion and
possibly of unwanted traffic. So I think there is a strong
argument that RFC 2606 values SHOULD be used whenever
reasonably possible.
That's my opinion; I'm not asserting that it's an IETF
consensus or that it necessarily applies to 2821bis. But I do
assert that it's a technical argument and not an editorial one.
Brian
Of course, the ballot in this particular case
<https://datatracker.ietf.org/idtracker/ballot/2471/> makes
no claims
about "technical confusion". I assume that when no
"technical confusion"
exists, you *would* consider such things "an editorial issue"? (A
misplaced comma or the use of the passive *may* cause "technical
confusion", but unless this is called out, the assumption is always
that such things are "editorial issues".)
pr
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf