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
DNSOP ietf.org
https://
www1.ietf.org/mailman/listinfo/dnsop
|