Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13

["Joel M. Halpern" <[e-mail]>]

Thank you for all your work on this.

While I still find the presence of the address allocation mechanism 
strange to find in this document, I can live with it.  So with this 
complaint done, I will shut up about it already.

Aside from some items noted below, this seems to be in good shape.

Moderate:

     Section 10.3.4 has a helpful discussion of some of the complexities 
of determining where to auto-enable the ACP.  I am a bit surprised not 
to see some discussion of which VLANs to enable for ACP in an Ethernet 
environment.  For WDM< since wavelength usage is configured, I presume 
that ACP would never try to auto-enable a frequency band?

Minor comments:
    In section 6.1.1 the text and the ABNF says that an rsub is a full 
domain (using the same domain-name construct as the "domain" which is an 
FQDN.  However, the example shows a partial domain string which is 
concatenated with the "domain" to produce an FQDN.  And the syntqx of 
"routing-subdomain" shows that concatenation.  This suggests that the 
text needs to be clear as to what the syntactic content of the rsub 
field is.  Might it be better not to define it as a "domain-name" but to 
define it as FFS, with a caveat that whatever usage is later defined 
needs to be suitable for combining with the "domain" for generating the 
hash for the ULA Global ID?  (Just to be clear, as written the text 
seems to end up with <domain<.<domain> where <domain> is from RFC 1034.

     Section 6.1.2 bullet one states that "The peer certificate is valid 
as proven by the security association protocol exchange."  I may be 
overstepping my knowledge, but I think there are two different things. 
First is the certificate validity, which is an internal property of the 
certificate.  The second is the certficate applicability which may be 
informed by the protocol exchange.
     Related to that, please put in a reference to which protocol 
exchange you mean?

     Either there is a document inconsistency, or there is a typo in the 
first paragraph of section 6.10.7.3, in that the address prefix length 
for the zone address sub-scheme is /127, not /126.


Yours,
Joel