----- Original Message ----- From: "SM" <sm@xxxxxxxxxxxx> To: "John Leslie" <john@xxxxxxx> Cc: "IETF-Discussion list" <ietf@xxxxxxxx> Sent: Thursday, December 22, 2011 10:10 PM > Hi John, > At 04:48 22-12-2011, John Leslie wrote: > > Surprisingly, a Google search on "ISBN 9780876094815" actually turns > >up something arguably appropriate: > > Which obviously is not about an IETF last call soliciting *company* > support. :-) > > > Brief skimming shows it to be much what I would expect from CFR > >(not worth my time to read carefully), and not attempting to change > >actual IETF process, though perhaps I missed something... > > Well, why bother changing a process when would be is easier to select > the decision-makers. Anyway, the current revision of the draft is > draft-ietf-sidr-rpki-rtr-22. > > In the Abstract Section: > > "In order to formally validate the origin ASs of BGP announcements, > routers need a simple but reliable mechanism to receive RPKI > [I-D.ietf-sidr-arch]" > > It would be better to remove that reference. > > draft-ietf-sidr-arch-13 could be a normative reference instead of an > informative one if the protocol described in this draft is part of > the infrastructure to support secure Internet Routing. > > In Section 2: > > "Global RPKI: The authoritative data of the RPKI are published in a > distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see > [I-D.ietf-sidr-repos-struct]." > > There isn't any mention of IANA, the RIRs or NIRs in > draft-ietf-sidr-repos-struct-09 or draft-ietf-sidr-arch-13. Odd; when I look at draft-sidr-arch-13 s1.1, I see IANA, RIR, NIR along with LIR etc. Granted I do not see RIRs or NIRs but I would allow the singular to stand for the plural. Tom Petch > > "Session ID: When a cache server is started, it generates a session > identifier to uniquely identify the instance of the cache and to > bind it to the sequence of Serial Numbers that cache instance will > generate. This allows the router to restart a failed session > knowing that the Serial Number it is using is commensurate with > that of the cache." > > The change was probably in response to the following comment in the > Secdir review: > > "The cache identifies its boot instance via a nonce, and the client > routers are supposed to record the nonce and discard all records if > the nonce changes. The nonce is only 16 bits, though, and the > probability of two boot instances choosing the same nonce is too high, > in my opinion." > > Section 3 mentions a deployment structure for RPKI and repeats some > definitions from the Glossary Section. > > In Section 5.9: > > "If error text is present, it SHOULD be a string in US-ASCII, > for maximum portability; if non-US-ASCII characters are > absolutely required, the error text MUST use UTF-8 encoding." > > A reference for the encoding could be added. > > Is the Integrity protection for payloads also desirable to protect against > man-in-the-middle attacks (RFC 4949)? > > Section 7 has a MUST implement for an unprotected transport. Lower > requirement levels are used for more protected protocols. Section 9 > mentions that: > > "Small End Site: The small multi-homed end site may wish to outsource > the RPKI cache to one or more of their upstream ISPs." > > The Secdir review mentions that: > > "The answer is a simple protocol that concentrates assuring record > freshness and punts security to some preconfigured point-to-point > communication with some kind of transport security." > > From Section 11: > > "As this document describes a security protocol, many aspects of > security interest are described in the relevant sections." > > Quoting a comment from an IETF participant: > > "The operator's server to the operator's routers only involves the > operator's internal network. While I would personally prefer a > mandatory-to-implement mechanism, I can see that operators do not > necessarily want prescriptive statements on this part of the > specification." > > The upstream ISP isn't part of the operator's internal network. > > Regards, > -sm > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf