Michael, I get a bit confused by the way your mail agent doesn't distinguish new and old text, but in line...
On 24/09/2017 08:35, Michael Richardson wrote: > > Toerless, thank you for this version. We are very very close! > Brian, Max, I invoke your name in my comments... please read and +1, > or disagree with me. > > I noticed in this version has two places with no space after the .: > > across the network.[RFC7575] defines the fundamental ideas and design > and it should be re-usable by all autonomic functions.[RFC7575] > calls > > > Can we avoid semantic/normative statments like "ACP routing table may include > multiple" in a terminology section? > > Change: > ACP (ULA) prefix(es) The prefixes routed across the ACP. In the > normal/simple case, the ACP has one ULA prefix, see Section 6.10. > The ACP routing table may include multiple ULA prefixes if the > "rsub" option is used to create addresses from more than one ULA > prefix. See Section 6.1.1. The ACP may also include non-ULA > prefixes if those are configured on ACP connect interfaces. See > Section 8.1.1. > > to: > ACP (ULA) prefix(es) The prefixes routed across the ACP. In the > normative case, the ACP has one ULA prefix as specified in > Section 6.10. The cases where multiple prefixes are present > are explained in Section 6.1.1, and use of non-ULA prefixes > are explained in Section 8.1.1. > > There are some good updates to the ACP domain. I want to bring up this issue > From BRSKI here: > https://github.com/anima-wg/anima-bootstrap/issues/20 > > I was suggesting that the information for the Pledge's CSR should be broken > up such that the pledge will create the right CN from the pieces, which it > needs to know anyway. I had suggested: > > "ACPinfo" : { "acp-prefix" : "fda379A6f6ee00000200000064000001", > "acp-prefix-length": 96, > "acp-plus-part": "area51.research", > "acp-domain": "acp.example.com" > } > > I don't like your text: > If the operator does not own any FQDN, it should > choose am FQDN format string that intends to be equally unique. > > I suggest that: > If they don't own any FQDN, then, aside from WTF?, that they form a > unique name as: $(uuidgen).example.com. > Or, perhaps that they use ${ULA}.example.com. > > the only real-life situation where this is going to happen is in a test lab > run by co-op students, and in that case, the software might as well have a > pre-configured default. > > ====== > > Brian, Max and I asked you to remove the EST requirements on announcements > From the ACP document. Toerless explained elsewhere why he thinks the duplication is needed. > ====== > ACP secure channel MUST imediately be terminated when the lifetime of > any certificate in the chain used to authenticate the neighbor > expires or becomes revoked. Note that is is not standard behavior in > secure channel protocols such as IPsec because the certificate > authentication only influences the setup of the secure channel in > these protocols. > > This is rather impractical to implement in real life, that's why IPsec > doesn't do that. I strongly suggest you sit down with some Cisco, Juniper > (Netscreen) and Checkpoint IPsec product managers, and ask them what they > actually do, and why. > > Assuming you really want to have this kind of behaviour, then the correct way > to do this is to make statements about the rekey intervals on the channels. > > ACP secure channels created with the use of certificates will include some > lifetimes for the certificates. The set of lifetimes includes: > 1) the expiry date of the certificate > 2) the lifetime of the OCSP response > 3) the validity time of the CRL response > > The earliest date provided by these provides a time at which the > keymanagement channel (e.g. IKEv2 PARENT SA) SHOULD be rekeyed. > > > 6.10.4. ACP Manual Addressing Sub-Scheme > > The sub-scheme defined here is defined by the Type value 1 (one) in > > was changed to: > The sub-scheme defined here is defined by the Type value 00b (zero) > > I think that this is a typo, and should be 01b ? > Or does the Manual mechanism somehow fit into the > ACP Zone Addressing Sub-Scheme because the Z bit is different? > > Do you explain this manual zone better somewhere? > > > Can you show the two Types with their bits set at the end of the base scheme? > > 64 64 > +---------------------+---------+---++-----------------------------+ > | (base scheme) 01|Subnet-ID| Z || Interface Identifier | > +---------------------+---------+---++-----------------------------+ > <-------48--------->TT 13 1 > > > section 8.8.1, starting at: > The ACP connect interface must be (auto-)configured with an IPv6 > > seems to be missing articles and/or words, and needs an english editing pass. > > ====== section 11 > This document may be considered to be updating the IPv6 addressing > architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast > addresses ([RFC4193]) depending on how strict specific statements in > > I don't like this statement. Either it violates the spec, and updates it, or > it does not. I do not think that it violates. This is not a multi-link > subnet, this is a prefix that is not on-link. As readers of the 6man list know, this has been a very contentious topic. I think it's safer to duck it in the ACP draft: say what we do, but say nothing about RFC4291 etc. > It is possible, that this scheme constitutes an update to RFC4191 > because the same 64 bit subnet prefix is used across many ACP > devices. The ACP Zone addressing Sub-Scheme is very similar to the > common operational practices of assigning /128 loopback addresses to > network devices from the same /48 or /64 subnet prefix. > > It does not. Brian? Do you concur? Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't assign them using SLAAC. It doesn't use conventionally sized /64 subnets. So in that sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router Links"). But we don't need to apologise. As you say, we're simply assigning /128 addresses to (virtual) interfaces using our own scheme. And we're relying on BCP 198 (RFC 7608) which says that routing prefixes can be any length up to /128. If you want to cite anything, cite RFC 7608. > The goal for the 8 or 16-bit addresses available to an ACP device in > this scheme is to assign them as required to software components, > which in autonomic networking are called ASA (Autonomic Service > > We are not providing 8-bit or 16-bit IIDs. > We are providing 256 or 65536 /128 addresses which are conveniently > aggregated for routing purposes. > > In practical terms, the ACP should be enabled to create from its /8 > or /16 prefix one or more device internal virtual subnets and to > start software components connected to those virtual subnets. > > No, don't say this, and don't do this in practice. Create /128 routes to LL > address of the internal VM and configure the /128 as a loopback address > inside the VM. So yes, I concur with Michael. Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
