Brian E Carpenter wrote: > Joe, ... >> Re-reviewing 2026, in all places the IESG is noted as being largely >> reactive to the community and guiding process. >> >> Only sec 6.1.2 notes the application of technical judgement, but only >> regarding maturity of the document and the standards level being sought >> - specifically as "technical quality and clarity". It specifically notes >> that (emphasis mine) "_independent_ technical review" can be solicited >> if there are issues of its impact on the Internet architecture. > > You are quoting very selectively. The context is rather different from > what you imply: > > In order to obtain all of the information necessary to make these > determinations, particularly when the specification is considered by > the IESG to be extremely important in terms of its potential impact > on the Internet or on the suite of Internet protocols, the IESG may, > at its discretion, commission an independent technical review of the > specification. > > In other words, the IESG gets to make the judgement call, but may choose > to get an independent review. This happens. As a matter of fact, I do > it every two weeks for all the drafts on the agenda, and Harald did it > before > me. It's all public, see > http://www.alvestrand.no/ietf/gen/art/gen-art.html. > >> Right now, the IESG is conducting its own, non-independent technical >> review - therein lies the issue, IMO. > > It's very clear that RFC 2026 sets the IESG up as the reviewer of > last resort (modulo the appeal process). I really don't understand > your issue except perhaps as a criticism of 2026. If the IESG isn't > to be the reviewer of last resort, who should it be? An independent body - one that doesn't get to decide the importance of its own review. Perhaps it is a criticism of 2026 if there are so many varying interpretations. ... > Conflict of interest is covered in RFC 3710 (which isn't a BCP, as it was > a first cut). Asking people to recuse themselves for conflict of interest is very different from not putting the decision in front of them. While the former is always required, it doesn't avoid the utility of the latter. Joe
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf