{reading the document before I read the thread of replies}
Thank you for doing this revision: this kind of work is often thankless.
A question as I read section 4.2 (The IESG).
I think that idnits presently finds and notes downrefs.
As a document shepherd, I've never had to research them.
(Maybe that's a fault on my part, maybe I should have been)
I'm mostly thinking that downrefs should ideally be noted and resolved during
WGLC. I think that this happens, but maybe I have too small a sample.
Are we having a problem getting downrefs identified early enough, or are
things okay?
I also wonder if we shouldn't have a process to attempt to clean the downref
registry out, but reclassifying the documents. The repeated MD5 and HMAC
document listed as examples seem like good datapoints. (MD5 might be
Historic, but HMAC is still awesome)
} At a minimum, authors/editors of source documents need to secure freely
} available copies of the target documents for use by all anticipated reviewers
} during the source document's life cycle, which includes working group
} participants, any member of the community that chooses to participate in Last
} Call discussions, area review teams, IANA expert reviewers, and members of
} the IESG.
It seems to me, if this requirement is to be taken seriously, that either the
DT or some other resource needs to contain notes on how to obtain the
references.
My opinion is that the IETF has allowed the IEEE to embrace and suffocate the
open-stand.org effort. During RFC8995 review, authors were told by many
about about 802.1AR had a new revision and shoudln't we update to it.
But, the new revision was unobtainable because the IEEE had 500 errors on
their web site for more than a year, which is why we did not cite it.
I feel that it shouldn't be just my problem to solve this problem on my own.
I have very strong opinions about what happens when a standard becomes part
of a lawful regulation. It then becomes part of a law, and the public
should have full access to know the law. (Because, ignorance is not a defense)
This is particularly important for regulations relating to safety.
(I could insert "cyber" before safety, but the word cyber is almost always
redundant). In particular, it shouldn't cost money to find out if a product
one is being subjected to is safe.
As background to a talk I was asked to do, I actually have been doing some
reading on requirements to publish laws, and I thought it would be a
no-brainer in the UN Charter, but I was surprised. Surely, Canada's 1982
Constitution and Charter of Rights would say something.... not obvious
actually. Just that anything published federally has to be in both official
languages, and a bunch of provincial statements. Some papers on how
governments have used copyright to generate revenue from publishing the laws
and legal decisions. Only the Yukon territorial constiution has an actual
mandate.
A reason I choose to do work at the IETF is because I could read the
specifications (using RFC/FTP by email...) without hassle.
So I am reacting the word "At a minium", and I don't think we are even
getting to that minimum. There are a bunch of specifications that aren't
just transitioning from some legacy specification to an RFC, but which we are
allocating numbers/etc. for entities which make it very difficult to read their
documents. I think that we should be doing more than the minimum here.
} Appendix A. Changes Since RFC8067
} The following are the changes in this document relative to the prior state of BCP 97:
}
} o Apply erratum #2793.
https://www.rfc-editor.org/info/rfc8067
doesn't mention any errata.
https://www.rfc-editor.org/errata_search.php?eid=2793 indicates that it is
errata against RFC4897.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
