As promised in Prague, here is a (late) review of
draft-jabley-as112-ops-00.
I believe that it is an important subject since AS112 plays an
important role and should be publically documented.
I see no significant problems in the RFC. It is quite different from
most RFC but it is not a problem in that case.
But, as the discussion in Prague showed, a lot of things in the
current AS112 practice could be changed (for instance,
hostname.as112.net could be replaced by the protocol which will
instantiate RFC 4892). So, I believe it is important to add a clear
statement that:
This document explicits the *current* practices of AS112 operators and
does not claim these practices are ideal. Its purpose is to inform the
community about the actual working of AS112, not to normalize best
practices.
Issues:
4.1 does not say if the operator should monitor the public IP address
(which requires a monitor in the BGP "drainage basin") or the
"private", the management one. (Without practical experience of
anycast, I cannot suggest a response.)
The last paragraph of the Security COnsiderations ("Operators of AS112
should take appropriate measures to ensure that AS112 nodes are
appropriately protected from compromise") is a bit useless. Because of
its nature, AS112 could be compromised not only by a cracker 0wNing a
node, but also by a rogue operator. This is not too far-fetched since
it is much easier to become an AS112 operator than a root server
operator.
Editorial issues:
References to I-D.ietf-grow-anycast should be replaced by RFC 4786
The list of routing software (3.4) and of nameserver software (3.5)
was compiled under which criteria? Only the software actually used
today in AS112? Or all the free software for that task? (In the case,
Xorp is missing from 3.4 and PowerDNS from 3.5).
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
