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

[Marshall Eubanks <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Brian E Carpenter
>> Sent: 16 June 2008 22:42
>> To: Pete Resnick
>> Cc: John C Klensin; [e-mail]; [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf
>>
>>
>>
>>
>
>
>
>
> _______________________________________________
> IETF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf