IETF Logo Mail Archive

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

Job Snijders <job@instituut.net> Sat, 19 November 2016 10:32 UTC

Return-Path: <job@instituut.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8054A129651 for <idr@ietfa.amsl.com>; Sat, 19 Nov 2016 02:32:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_ND9YgMmibV for <idr@ietfa.amsl.com>; Sat, 19 Nov 2016 02:32:32 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4261712946F for <idr@ietf.org>; Sat, 19 Nov 2016 02:32:32 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id g23so73444558wme.1 for <idr@ietf.org>; Sat, 19 Nov 2016 02:32:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+i8vUkcGD2zC9313w6hSMUZQI0yEkwKD5L5YOEjoYas=; b=trKXOftAi0SduYvMkpBb7EAFvhF8QiJzSwHezvHGnV3H2vM26oa0s547HGTtJat5Su N8T4AxvvD6z6CpT44ZUjxicQ1Dk3dUn4UI8WcyfK+spCe/ds9aUlScDPrP84oDuFwTtD dy9W7ERiSYrxvhTDeokUB3TOql6zxav8C7FAYTAkMpI82O9zZ1hZ3OvO81uAwrHLZIbq VFjzIfeF47+1PswA7Y7qnOe6G6o3PNVi9vH7GLc5ggyUK0FEoTbyaEbNU0ol8XcNMyre 4gCz16I+AO0edH7HDq4wVNQdtSq80vb4JpVnqbCVHHktQWKk0AE2c3GLWIZ59NEdQUcq a3/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+i8vUkcGD2zC9313w6hSMUZQI0yEkwKD5L5YOEjoYas=; b=RIa0erpyujNiyJtbD+RQh4KCAinJWRv6BlfWU8z3VO13amzsq3cnjnVof7yNusSUGo MS3D+AEQewEoIXcsLchLSsUaxAn/iWT5JhPqx0jbtXp0VdF6Ggw5JWYgBuavF9lA3Bd/ lsjGLAtCVMDLBNZWNyQFZCpm3JdlNZqWfUIXODVXOahfRStp6TlrOETuEAWYnPJ3vWNl XiNoHrkT7Ucq8CXmsDwn6uk39cN60Syzzfp8Ge10CdTs66FGShXvxJRhHl+ZrbPHgMp4 FCAO67BOccKPeTJwGR1pkEk65VBRfKudSTY3nHOUxUbQSdu0kpBpyD9zzjUeM6hStfbg FKNw==
X-Gm-Message-State: AKaTC03yogCRsxyrH1DEi8kXFw0Wu9sczUi0/N0X2QrtabpDhcr28DIMpcOq0PfBvKX0Pg==
X-Received: by 10.28.149.79 with SMTP id x76mr2774736wmd.27.1479551550505; Sat, 19 Nov 2016 02:32:30 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:1d57:e1da:9ff:e79d]) by smtp.gmail.com with ESMTPSA id v10sm13524273wji.29.2016.11.19.02.32.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Nov 2016 02:32:28 -0800 (PST)
Date: Sat, 19 Nov 2016 11:32:26 +0100
From: Job Snijders <job@instituut.net>
To: idr@ietf.org
Message-ID: <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup> <CACWOCC8ENYuX2LeJKWP0tmMoCPJ4J-qxJjOXiHHLaP8Fqe4USg@mail.gmail.com> <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <37224750-4065-40E3-B6F4-571DED698563@cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-c6OpW4DC_FL-2TwUTwyyOspCTM>
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Nov 2016 10:32:34 -0000

Hi Jakob, Working group,

It is for "defensive" purposes: what if utf8 turns out to be terrible,
then cease subcode 2 can still be used but we can put something else in
the datafield trailing the subcode.

the advantage of using a length field is that we avoid discussing types
and semantics, but future protocol developers have an option to use the
trailing data in the NOTIFICATION message for some purpose.

It would look like this:

-----

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Error code 6  |   Subcode 2   |    Length     |     ...       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   ... Shutdown Communication ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:
        The Length value can range from 0 to 128 and indicates how many
        bytes of UTF-8 for the Shutdown Communication follow. If the
        length field is set to 0, no UTF-8 bytes follow.

-----

This is an very lightweight approach to leave the door somewhat open ,
should the need to do something else with the trailing data arise, and
it only costs 1 byte.

Kind regards,

Job


On Fri, Nov 18, 2016 at 08:01:30PM +0000, Jakob Heitz (jheitz) wrote:
> Not necessary. You can already send whatever you want. In iOS-XR, it
> just hexdumps it all. The only thing that will change is that it will
> print it in UTF8 as well. It will still hexdump. If you want no
> hexdump, then we need a new subcode.
> 
> Thanks,
> Jakob.
> 
> On Nov 18, 2016, at 12:52 AM,
> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:
> 
> Thanks.
> --Bruno
> 
> From: Job Snijders [mailto:job@instituut.net]
> Sent: Friday, November 18, 2016 9:46 AM
> To: DECRAENE Bruno IMT/OLN
> Cc: Jeffrey Haas; Job Snijders; grow@ietf.org<mailto:grow@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
> Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
> 
> Hi Bruno,
> 
> John Scudder was kind enough to provide extensive argumentation
> offlist on why something along these lines should be done. We'll work
> on a proposal. The length indicator is a neat idea, thanks for
> sharing.
> 
> Job
> 
> On Fri, 18 Nov 2016 at 17:32, <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:
> 
> 
> > From: Job Snijders [mailto:job@instituut.net<mailto:job@instituut.net>]  > Sent: Friday, November 18, 2016 1:46 AM
> >
>  > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote:
>  > > I support the draft.
>  > > I also support Jeff's idea to re-use existing sub-code(s).
>  >
>  > Thanks for your support. Based on the feedback received so far the next
>  > version of this draft will recycle Cease subcode 2.
>  >
>  > > 1 possible comment: the length of the "Shutdown Communication" field
>  > > seems implied from the length of the data field, rather than being
>  > > explicitly indicated.
>  >
>  > The text is explicit about the length:
>  >
>  >     "followed by a freeform UTF-8 encoded string with a REQUIRED maximum
>  >     length of 128 octets. "
>  >
>  > and further:
>  >
>  >     "This document tries to minimize the effects of visual spoofing by
>  >     allowing UNICODE only where local script is expected and needed, and
>  >     by limiting the length of the Shutdown Communication."
>  >
>  > > If so, it seems that we are closing the possibility to advertise
>  > > additional data/usage, in some future. What about adding a TLV format?
>  >
>  > I object to using a TLV. Don't forget this is already at a TLV level:
>  > Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
>  > new Cease subcode can be requested from IANA.
> 
> What if someone needs to advertise additional info to an existing
> cease subcode? cf Jeff's email regarding the pain of changing
> subcodes.  So let's forget about the TLV. What about just adding the
> length of the string? This would still allow adding fields after the
> string, while having a negligible/null cost?
> 
> Kind regards,
> -- Bruno

v2.23.0 | Report a Bug | By Email