A) It's too early for nit edits
not really. as the iesg has approved this one, changes are going to be
a process pain. so this message pushes back on some of your suggestions
which i would otherwise have gladly taken.
perhaps the sponsoring AD will give me/us some guidance in this.
also please excuse the roughness of my response. i just hit san diego
from a few time zones to the west.
5.1, 3rd paragraph(/sentence): is only -> is *the* only
done
B) 5.9: the 2nd and 4th paragraphs seem to contradict each other. I
suspect that the intent is that you can send a generic error after a
particular PDU, but the way it's phrased is a bit odd and it jumped
out at me too. How about:
If the error is generic (e.g. "Internal Error") and not associated
with the PDU it is responding to, the Erroneous PDU field ...
sure
C) 5.10 seems to indicate rcynic
not in -26
D.1) "Unfortunately there is no protocol to do so on all currently used
platforms".
I actually doubt the validity of that statement. I suspect SSH is
likely available on them all.
no it is not. see voluminous discussion on list. to save you the
search, very common router platforms provide hard coded ssh client and
server, but no ssh library which a protocol such as this can use.
Or at least "nearly all" (and I doubt anything will ever reach
"all"). I'd bet TLS is nearly ubiquitous as well, though
probably less than SSH.
about the same mess
D.2) The ordering of the 5th-8th(ish) paragraphs seems weird. I'd group
them together by subject such that the sections that talked about
unprotected TCP should be next to each other and the ones that
talked about the protected ones be together. Thus, I think just
moving the 2 unprotected paragraphs ("Caches and routers MUST..."
and "If unprotected TCP...") to positions 5 and 6 would solve most
of the oddities.
not sure this is sufficiently problematic to tempt the $dieties post
iesg approval.
D.3) I'm not sure that the whole concept of "MUST implement unprotected"
is going to fly through a security review.
it did. after a bit of discussion.
D.4) There is some confusion regarding whether routers "use" vs "can be
configured to use". EG: "Caches and routers SHOULD use TCP-AO..."
IMHO, this indicates they have a choice. "SHOULD be able to use"
might be a better wording choice implying its subject to
configuration by the operator. If you want a more complete list of
places where I think this might be a problem, I can supply one of
course.
not sure this is sufficiently problematic to tempt the $dieties post
iesg approval.
D.5) "If available to the operator...". How would the router know
what's available to the operator? Or does this mean that if the
device already implements protocol X, it must offer it as a
configuration choice for rpki-rtr transport? If so, that's not
entirely clear.
i think the meaning is pretty clear, though i guess it could be better
phrased. but it has to be available on *both* router and cache server.
D.6) I'd order the sub-sections to be in the same order as the list
above it. IE, TCP-AO is first in the list, so the TCP-AO
sub-section should probably come first.
probably. but it may be safest to let the rfced hack it.
E) 7.1 SSH transport "Client routers SHOULD verify the public key of the
cache". Similar to D.4, I'd change this to "Client routers MUST
be able to verify the public key of the cache".
the looser but riskier phrasing was not an accident.
F) 7.2 TLS transports: the CN field is really being deprecated and I'd
suggest using the subject alt name instead (SAN).
see -26 for a complete rewrite of the tls section
G) section 8, paragraph 2 implies that the cache needs a list of names
for the peer and I'm not sure this is true. In fact much of that
paragraph talks about the router/client side only, so I'd split the
paragraph in two: one for cache requirements and one for the router
requirements.
H) section 8: I'd change "Key" to either "TheirKey" or "ItsKey"
if so, probably should be CacheKey. but whose key it is seems very
clear from the next few words, yes?
I) section 8: "it would be prudent for the client"... This seems like a
good place for the word SHOULD to sneak in there somewhere.
eenie meenie. did not see a need to be that strongly prescriptive.
J) section 8: "if data from multiple caches are held, implementations
MUST NOT distinguish between data sources when performing
validation".
This one confuses me. It's unclear, after reading the entire
document, why you have a preference ordered list if the data from
them all must be treated equally.
proximity and security
randy
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
