On Mar 6, 2008, at Mar 6, 2008,8:55 PM, Brian E Carpenter wrote: > On 2008-03-07 14:06, Lakshminath Dondeti wrote: >> Brian, >> >> A small clarification below on the reference to the interpretation >> problems related to 3777: >> >> On 3/6/2008 4:10 PM, Brian E Carpenter wrote: >>> Dave, >>> >>> On 2008-03-07 12:34, Dave Crocker wrote: >>>> Sam Hartman wrote: >>>>> Making it a BCP will make the interpretation problem worse not >>>>> better. >>>> >>>> How? >>> >>> To some extent that depends on how carefully the putative BCP >>> is crafted, with "should" and when to disregard "should" being >>> very precise. What I think we've seen, with 2026 over the years, >>> and apparently this year with 3777, is that it's virtually >> >> I am not sure whether you have made it to the appendix in my >> report, but >> the disagreements in interpretation of 3777 have a history (see Page >> 37). The only thing special about the current nomcom is that we >> chose >> to bring it to the community's attention. In Ralph's case, he >> brought >> it to the IESG and IAB's attention in March 2006. > > That's true, from my personal knowledge since I was in the IESG > at that time. However, that supports my point ;-) . > > (Not to be defensive, but the only changes in RFC 3777 that Ralph > specifically recommended were the ones covered in RFC 5078). > > Brian Brian - you might be right, but only on a technicality. I noted that a clarification in RFC 3777 in the definition of the term of a mid- term appointment was needed, but didn't give a specific recommendation. More to the point of Lakshminath's observation, I explicitly pointed out the conflict between RFC 3777 and the IAB requirements statement to the IAB and the IESG; I didn't recommend a change to RFC 3777 mostly because I thought it was the IAB requirements that needed to change. - Ralph > > >> >> thanks, >> Lakshminath >> Nomcom 2007-8 Chair >> >>> impossible to write precise procedural text that deals with >>> completely unexpected circumstances. Yet if the text has the >>> force of a BCP, it becomes very hard to interpret it flexibly >>> when flexibility is clearly needed. I don't know if that >>> is Sam's point, of course. >>> >>> Brian >>> _______________________________________________ >>> 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