[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf
Subject: Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"
From: Stewart Bryant <stewart.bryant () gmail ! com>
Date: 2021-05-12 16:51:52
Message-ID: D3E64BB8-CBA5-4757-AF13-8EA373BD7DDC () gmail ! com
[Download RAW message or body]
> On 12 May 2021, at 16:46, tom petch <daedulus@btconnect.com> wrote:
>
> Second, you say that 'Hold for Document Update' makes it painfully clear that there \
> is no IETF consensus on the problem. I disagree. The Editor page says that this \
> status says that it is not a necessaary update, may be considered for a future \
> update which to me has always implied that this may not be an error at all, rather \
> out of scope at present, a request for a functional change, such as to make a \
> product compliant to the RFC:-). SO there may be a clear consensus, not right at \
> this time.
Yes there are many reasons for HFDU. One is that the issue is a technical change that \
is out of scope for an erratum, but does need to be addressed when an updating or \
replacing RFC is published. It is assumed that the change is not urgent when HFDU is \
used,There is another that is closer to your point in that the erratum problem is \
valid, but would take significant work to address, and the base document itself is \
obsolete so no harm is done in leaving the issue on file.
So long as we have technical experts as ADs and not career specialist managers, the \
system we have with the significant degree of discretion that we impart to the ADs \
and associated errata classifications works acceptably well in my view.
If a fix to an erratum is incorrect it can always be replaced, a second erratum \
created or an updating RFC published. We should continue to use the pragmatic and \
reasonably flexible process that exists and seems to work, rather than try to design \
a fixed "perfect" approach.
- Stewart
[Attachment #3 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On 12 May 2021, at 16:46, tom petch <<a \
href="mailto:daedulus@btconnect.com" class="">daedulus@btconnect.com</a>> \
wrote:</div><br class="Apple-interchange-newline"><div class=""><span \
style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 14px; \
font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: \
normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; \
float: none; display: inline !important;" class="">Second, you say that 'Hold for \
Document Update' makes it painfully clear that there is no IETF consensus on the \
problem. I disagree. The Editor page says that this status says that it is not \
a necessaary update, may be considered for a future update which to me has always \
implied that this may not be an error at all, rather out of scope at present, a \
request for a functional change, such as to make a product compliant to the RFC:-). \
SO there may be a clear consensus, not right at this \
time.</span></div></blockquote></div><br class=""><div class="">Yes there are many \
reasons for HFDU. One is that the issue is a technical change that is out of scope \
for an erratum, but does need to be addressed when an updating or replacing RFC is \
published. It is assumed that the change is not urgent when HFDU is used,There is \
another that is closer to your point in that the erratum problem is valid, but would \
take significant work to address, and the base document itself is obsolete so no harm \
is done in leaving the issue on file.</div><div class=""><br class=""></div><div \
class="">So long as we have technical experts as ADs and not career specialist \
managers, the system we have with the significant degree of discretion that we impart \
to the ADs and associated errata classifications works acceptably well in my \
view.</div><div class=""><br class=""></div><div class="">If a fix to an erratum is \
incorrect it can always be replaced, a second erratum created or an updating RFC \
published. We should continue to use the pragmatic and reasonably flexible \
process that exists and seems to work, rather than try to design a fixed "perfect" \
approach.</div><div class=""><br class=""></div><div class="">- Stewart</div><div \
class=""><br class=""></div><div class=""><br class=""></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic