Brian, As a matter of personal preference, I would very much prefer not to see process constructions that require repeated use of the status in order to disambiguate the meaning of the status. In other words, having to clarify that a DISCUSS is (really) a discuss (and presumably not something else) is not the way to clear things up - not even "clear enough." Either DISCUSS means what it implies (maybe we add some separate status for BLOCK), or we change the state name to an intentionally more ambiguous name (like HOLD, or PENDING). -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Brian E Carpenter > Sent: Sunday, June 15, 2008 6:00 PM > To: John C Klensin > Cc: iesg@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Appeal against IESG blocking DISCUSS on > draft-klensin-rfc2821bis > > Regardless of John's P.S., I'd like to make some comments > that the IESG may wish to consider: > > On 2008-06-15 05:11, John C Klensin wrote: > > > > --On Saturday, 14 June, 2008 10:44 -0400 Eastlake III > > Donald-LDE008 <Donald.Eastlake@xxxxxxxxxxxx> wrote: > > > >> Standards track RFC 4343 was issued within the past five years > >> (January 2006 to be precise). It contains some example domain > >> names that do not follow the suggestions in RFC 2606 as well > >> as some that do. As the author of both RFC 2606 and RFC 4343, > >> I believe the domain names reserved in RFC 2606 were intended > >> to be encouraged but not mandatory. > > > > Donald, > > > > Thanks. The fact that those recommendations have not been > > consistently been treated as mandatory doesn't really affect the > > core of the appeal, but it further weakens any claim that this > > behavior is ok based on a consistent (even if unpublicized) > > pattern of prior IESG behavior and decision-making. > > 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. I'm not > asserting which > applies to 2821bis, but I do assert that there is scope here for > a judgement call and therefore the inconsistency is understandable. > > 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. [For the record: > I ballotted NO OBJECTION on RFC4343.] I regard the DISCUSS > that John is appealing against as a judgement call. It isn't clear > to me that it's a stylistic or editorial comment by construction. > > To the underlying process issue, a DISCUSS based on a judgement call > is always a little tricky. However, if the document shepherd can show > that the call made in the draft was an explicit rough consensus, it > does seem like the sort of case where the DISCUSSing AD might choose > to switch to an ABSTAIN. > > I strongly agree with John's suggestion that ADs should > clearly distinguish > a comment where they really want discussion from something > that they view > as a sticking point. One of the cleared DISCUSSes on 2821bis > starts thus: > "This is a discuss discuss question....". Is that clear enough? > > Brian > > > > > best, > > john > > > > p.s. while I appreciate the comments I've received expressing > > support for this appeal, I'm generally not going to respond to > > them on-list lest the IESG interpret the comments as part of a > > lobbying effort. The procedures say that appeals go to the > > IESG and the IESG decides (then they may go elsewhere). I don't > > believe that there is any prohibition on the IESG's asking for > > community input if they want it, but they are certainly under no > > obligation to do so or to consider such input as part of > > considering the appeal. This note is an exception only because > > it identified a fact I didn't have available when I wrote the > > appeal text. > > > > > > > > _______________________________________________ > > IETF mailing list > > IETF@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > IETF mailing list > IETF@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf