Tim,
On Wed, Nov 04, 2020 at 06:01:14PM +, Tim Evens (tievens) wrote:
> I've updated this to UTF-8. From a receiver point of view, we handle utf-8
> generically without any special need to deserialize it. I suggest we do not
> attempt to define structure and/or constraints around the VRF
ow-bmp-local-rib-07 (preparing for
sheperd write-up)
Dear Tim,
Hi Tim,
On Wed, Nov 04, 2020 at 05:49:48PM +, Tim Evens (tievens) wrote:
> [tievens] Agree. The draft itself has local in the name. Does it make
> sense to change the draft name or keep it as is?
The filename is not relevan
Dear Tim,
Hi Tim,
On Wed, Nov 04, 2020 at 05:49:48PM +, Tim Evens (tievens) wrote:
> [tievens] Agree. The draft itself has local in the name. Does it make
> sense to change the draft name or keep it as is?
The filename is not relevant, I'd leave it as-is. Ultimately the
document will have
Jeff,
I've updated this to UTF-8. From a receiver point of view, we handle utf-8
generically without any special need to deserialize it. I suggest we do not
attempt to define structure and/or constraints around the VRF names as that
would severely impact system implementations that are
I really appreciate your review and comments. These are great.
See responses inline marked [tievens].
You can see the "pending" changes via:
* https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib/pull/19/files
*
Job,
I agree that utf-8 is more appropriate, but would remind you that a great deal
more text about handling it would be needed. See prior discussion on RFC 8203.
Jeff
> On Nov 3, 2020, at 1:29 AM, Job Snijders
>
> ### note 8
>
> section 5.3
>
> Curious: why ASCII and not UTF-8 (of which
