Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

[tom petch <[e-mail]>]

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 <[e-mail]> 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 [e-mail] (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   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
>