Final comments/actions on Toerless' awesome review. The -13 is coming out soon, but we have 13 issues to resolve still.
>
-----------------------------------------------------------------------------
> Section 8)
> a) First paragraph: Unvailable MASA is not a security but an
> operational consideration.
> Feel free to add "Operational considerations" section before security
> considerations and move it there. Might want to add some more
> considerations around
> MASA to set context: Suggest something like:
It's due to that operational consideration that someone might want a nonceless
voucher, and therein is the security consideration.
So while I'm not oppposed to an Operational Considerations section,
it would not start with that first paragraph.
> c) "The MASA authorization log..."
> Not security consideration either IMHO. Suggest to move into a new
> "Privacy considerations"
Agreed.
MAX: when did the MASA audit log became an authorization log?
Is this intentional?
>
-----------------------------------------------------------------------------
> Appendix A)
> a) Would change title to non-IPv6 or non-ANI operations:
> b) Initial explanation:
I'm changing it to IPv4 and non-ANI operations.
I'd rather search found "IPv4"
> Specification of BRSKI in Section 4. only covered the mechanisms for an
IP6
> Pledge (link-local IPv6 address) and Proxy options necessary for IPv6
> and ANI.
> It does not cover the options for non-IPv6 Pledge or non-ANI Proxies
> (IPv4 or IPv6).
done.
>
-----------------------------------------------------------------------------
> Appendix A.2)
> a) Replace with:
> A.2. Use of DHCP
Not sure I agree. I think that DHCPv6 considerations are very different.
There are RAs, DHCPv6, as well as what kind of address will be given.
An IPv4 address is almost 100% certain to be RFC1918/NAPT, while IPv6 will not.
I don't mind adding a section on this, but I'd prefer to have a seperate
section as it needs significantly more details.
>
-----------------------------------------------------------------------------
> Appendix B)
> a) Use suggested service name of "_brski-proxy" in all caes where
> "_bootstrapks"
> is used. (see comment for section 4.1.1 for why that name is better).
Opened issue: https://github.com/anima-wg/anima-bootstrap/issues/57
> b) After "The Pledge MAY perform DNS-based Service Discovery", new
paragraph:
> A non-ANI Proxy MAY perform DNS-based Service Discovery using unicast DNS
> to discover Registrars searching for searching for the service
> "_brski-registrar._tcp.local.".
okay.
> c) "To prevent unaccceptable levels of network traffic" -> add ", when
> using mDNS"
okay.
> d) "received a useable IPv4 address via DHCPv4 as suggested in Appendix
A" ->
> "received a useable IP address via DHCP/DHCPv6 as suggested in Appendix
> A.2"
see above.
> e) "If no local bootstrapks service": Add at end of paragraph: See
> Section 2.6 (Cloud Registrar).
done.
>
-----------------------------------------------------------------------------
> Appendix C)
> a) See discussion for section 4.3 above for the issues i see with
> current IPIP
> specification and suggestion to maybe move out of BRSKI to resolve with
> more time.
Yes, I think that I agreed to remove it.
>
-----------------------------------------------------------------------------
> Appendix E)
> a) Please add a sentence how to decode Hex Certs (not keys) with utility
> at the very top of the appendix (right now its further down in the
> text).
I'm confused by this.
a) there are no Hex Certs, they are all base64, and they are in standard
PEM format.
b) I never say how to decode them... so?
> b) E.1.4: which element in the cert would become the serial-number ?
Good point, it's not in the Subject in this example.
https://github.com/anima-wg/anima-bootstrap/issues/58
I expect to regenerate the examples at AUTH48 time, once IANA
has assigned everything.
> c) There are no ASN1 decodings of the artefacts, Please fix.
> If this is subject to IANA assignments, please add RFC editor note to
> block draft progressing.
Sorry? Which one is missing?
> X) Applicability outside ANIMA
> If i am not mistaken, BRSKI-MASA should be one option how a bootstrap
> server in "draft-ietf-netconf-zerotouch" could obtain a voucher from a
> MASA (if i understand it correctly, the mean by which such a bootstrap
> server obtains a voucher is left open). If that is correct, then it would
> be great to mention this in a sentence or two in an appropriate section
> of BRSKI as a very explicit example how BRSKI can be reused outside the
> complete ANIMA scope (also add draft-ietf-netconf-zerotouch as an
> informational
> reference).
I would prefer to let ietf-netconf-zerotouch do that.
Or a new document in netconf, to be done after we finish BRSKI.
Otherwise, I think we wind up with too close coupling, and cycles
in the review process.
DONE your comments.
Many issues open.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
