Michael
My e-mail has been rendered almost unusable so I struggle (I cannot
access the I-D or much else from this PC:-(
My comment about XXXX is that you ask RFC Editor to supply the RFC
number for an I-D with a name you give but that name is not the same as
the name at the front of the I-D:-(
When I see [RFC8446] those square brackets make me suspect HTML/XML
which must not appear in the YANG module which must be plain text.
Security Considerations, the YANG Guidelines RFC says that you must
mention TLS, HTTPS, etc and give pro forma text for doing so. As long
as you still have a YANG module, as you do in s.3.4, I would expect
those guidelines to apply and so to see something like the pro forma text
HTH
tom petch
with apologies to the IESG for all this noise - I would like to drop
them from the Cc: list but do not quite dare.
On 31/12/2019 19:37, Michael Richardson wrote:
A diff against -31 is at: https://tinyurl.com/vuls2ge
and will grow to include my responses to Ben's 2019-12-20 comments later today.
tom petch <[email protected]> wrote:
> Yes you have removed the second YANG module which addresses my comments
> about the second YANG module but my other comments mostly remain.
> Those about the YANG prefix are fixed.
> RFC8040 needs to be in the I-D References
> IANA Considerations mentions the removed module but lacks the two
> required actions for the remaining module
I understand now. I wonder if idnits could be taught to find such issues :-)
Please see commit:
https://github.com/anima-wg/anima-bootstrap/commit/75d7ef8a78b2c03cd2e558705861194357f1e643
> XXXX is used as a place holder for a document name which is not that of
> this I-D and does not exist AFAICT
Do you mean the self-reference should say "XXXX"? I have used "THIS
DOCUMENT" in the past.
> The YANG module must be plain text - [RFC8446] looks like HTML/XML
I'm confused by this comment. I see:
> Michael, my initial posts were a response to the Genart review and so
> did not include your name, just Anima, Anima chairs, ibagdona, IETF;
> you are in this one as [email protected] (but IETF mailers may have
> a habit of thinking you will get an e-mail via one way and suppress
> other ways with different e-mail addresses).
Yes, I wasn't complaining about your actions, but more just lamenting: my
impression is that the problem is that DMARC is getting in the way, since the
DT acts as a remailer. However, btconnect.com has a p=none policy, so it
shouldn't be a problem... however, maybe it fails the SPF tests themselves.
{I was forced to switch spam processing systems in the spring, and it really
has been a PITA to get it configured sensibly. Very few of them support
IPv6, and a surprising number of them will not use TLS for final delivery.
I specifically need to whitelist everything coming from the IETF SMTP machine,
and I don't think I've accomplished that perfectly yet.}
leaf proximity-registrar-cert {
type binary;
description
"An X.509 v3 certificate structure as specified by RFC 5280,
Section 4 encoded using the ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690.
The first certificate in the Registrar TLS server
certificate_list sequence (the end-entity TLS certificate,
see [RFC8446]) presented by the Registrar to the Pledge.
This MUST be populated in a Pledge's voucher request when a
proximity assertion is requested.";
}
I'm not sure I see how you are seeing HTML here.
If you are looking at:
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-31#section-3.4
then the links you are saying are because the HTMLizer sees the reference and
HTMLizes it.
> Security Considerations lacks the required boiler plate for a YANG
> module
I see. I have adapted the text from RFC8366, as we extend it, and the normal
template does not apply.
Fixed in commit:
https://github.com/anima-wg/anima-bootstrap/commit/c138bbd24db038f0704770b545e74ba202a98e4e
> Appendix A still has a typo
secification -> specification. plege->Pledge.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
