In looking around at existing crates that dealt with ASNs, I did not find one that handled parsing/formatting across all of the available notation formats. As this is my first real crate that is intended for others to use, I would welcome feedback of any kind.
Bit of a shameless plug, but I've created a similar crate; asn
The project this was intended for ended up on the backburner, so the crate is unfinished but should be usable and was also an (interrupted) ASN basics learning experience for me
I'll give some comments and indirect feedback by comparison. Doesn't mean one implementation/choice is better, mostly just (my) preference.
Your crate README has a high-level explanation, mentions relevant RFC and has example code, great! (I'm also a fan of badges in the crate README)
I'd replace the unwrap() with ? though, see Documentation - Rust API Guidelines
Crate description is also succinct
Crate has keywords, though I think only bgp and network add something that is neither in the description nor readme
Crate has no categories. I've put mine into parser-implementations even if that's a bit of a stretch
License is MIT only and not the common MIT OR Apache-2.0
Crate top-level rustdoc is similar to README
Main struct rustdoc is similar to top-level and README
There's some more constants that might be useful, compare from Asn in asn - Rust
There's one const constructor, good!
All the usual impls are there, compare from Interoperability - Rust API Guidelines
Expected FromStr and From<T> are there
Types are Clone or even Copy, Send and Sync, compare from Interoperability - Rust API Guidelines
Errors implement Error, Interoperability - Rust API Guidelines
Not sure about errors being a pub enum. Some prefer having this an internal detail, unless the user is expected to match on the error.
There's 100% rustdoc coverage
There's unit tests
There's no standalone examples/, but they'd be a bit redundant with such a minimal crate
Types do not implement serde traits, see Interoperability - Rust API Guidelines
Don't think there's general consensus on it, but I sometimes also like for schemars and arbitrary interoperability crate features
There's dependencies and they got proc macros
Some prefer to have as few indirect dependencies as possible and I think, while slightly less convenient for the crate author, this is usually a good idea unless they're strictly needed for core functionality or contain vetted unsafe
Some people like to have a documented (and tested) Minimum Supported Rust Version (MSRV) for their dependencies, but might not be that important for such a minimal crate
Speaking of core, the crate is not no_std even though it mostly could be, other than the alloc::String parts
Again preference, but I like no_std crates because they're usually more compatible with e.g. WASM or embedded targets.
Sometimes it doesn't make sense to gate core functionality behind alloc and std crate features though because that's not their envisioned usage
Now for that "to xyz String" part, it might be preferable to have functions that return Display wrappers, see Display in std::fmt - Rust
If there were only 2 formats, one could (ab)use the alternative format specifier Formatter in std::fmt - Rust
Since my crate is lacking the other formats, I'd also welcome feedback on design here 
@robo9k thank you for the insight here! I have gone ahead and implemented the required changes to make this crate no_std. That was great feedback. I will continue to work through your other suggestions as well.
Arbitrary would be great for testing the roundtrip property of both of our implementations. ie: does a display, then subsequent parse produce the original Asn type? I'm excited to get to that and it feels like a good fit for you as well.
One design decision I have since made was to still be able to parse all 3 formats but to just default display to asdot. This came based on some discussions with my team while using some of these ideas in a recent feature.
Maybe the error enum in my crate is overkill but I did feel it was helpful to be able to enumerate the potential reasons why parsing might fail.
Look forward to talking through anything else you think of 