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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]