Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Job Snijders <[e-mail]>]

On Wed, Nov 16, 2016 at 08:19:45PM -0500, Jeffrey Haas wrote:
> On Wed, Nov 16, 2016 at 10:01:10PM +0900, Job Snijders wrote:
> > Unless some implementors make significant arguments along the lines of
> > "we CANNOT implement this Shutdown Communication functionality, SOLELY
> > because of utf8 and lack of representation filtering capabilities", i'd
> > water down the utf8 requirement to 7bit ascii (because in the end its
> > better to have 'something' than nothing). Another line of argumentation
> > against utf8 would be if major security concerns are articulated.
> 
> In general, IESG comments will push any user-displayable string to UTF-8
> anyway, so I wouldn't stress over this being the requirement.  It's pretty
> much an IETF-wide expectation these days.
> 
> I think your doc is the first one that I've seen bothering to cite the
> unicode considerations documents.  Ideally that'd be a pointer to somewhere
> else in a single ref, but I don't think I've seen such an IETF document.

I took inspiration from syslog's security considerations https://tools.ietf.org/html/rfc5424

> > I hope to capture in the draft that an implementation can choose which
> > characters of the Shutdown Communication they represent in the syslog or
> > 'show bgp neighbor xxx' output. For instance, I'd recommend to squash
> > all newline/newpage/newfeed/newparagraph style chars and make sure that
> > the Communication is represented on a single line. I don't have the
> > proper words for the draft to express that (yet).
> 
> Again, perhaps too much to tackle in this document.
> 
> A portion of what you're interested in is covered under the control
> characters section:
> 
> https://en.wikipedia.org/wiki/Unicode_control_characters
> 
> If you try to get too normative you're going to spend a huge amount of text
> trying to close all of the holes.

Yes, and UNICODE is somewhat of a moving target, a wall of text won't be
effective.

> > Also I don't mind if an implementation consciously chooses to only
> > represent 7bit ASCII. That should be an implementor decision. They can
> > upgrade later. In theory the protocol spec shouldn't be delayed or
> > obstructed due to an implementor's current internationalisation
> > capabilities (which can change over time).
> 
> ASCII is conformant UTF-8, which is one of the nice properties about that
> encoding.  What tends to be problematic in many people's implementations is
> emitting Latin-1 or similar encodings that are 8-bit as if they're valid
> UTF-8, which they're not.
> 
> The better question is what the general expected behavior is when things
> cannot be displayed.  Some of that will depend on the i18n capabilities of
> someone's implementation.

I'd just skip over them.

grã©gory -> grgory

Kind regards,

Job