Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT)

"Asmus Freytag (c)" <asmusf@ix.netcom.com> Sat, 23 April 2016 18:03 UTC

Return-Path: <asmusf@ix.netcom.com>
X-Original-To: lager@ietfa.amsl.com
Delivered-To: lager@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4A112D0EE; Sat, 23 Apr 2016 11:03:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.819
X-Spam-Level:
X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.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 FuqWN-mPyuUc; Sat, 23 Apr 2016 11:03:47 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD6A12B01E; Sat, 23 Apr 2016 11:03:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=MG346V9VD5FIXviT1fV+0vyl0mniXJcXXwqNylq9HoBNfbH1jsdSk/lJ4imfwRwO; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [71.212.2.16] (helo=[192.168.0.4]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <asmusf@ix.netcom.com>) id 1au1tg-0003FX-Bt; Sat, 23 Apr 2016 14:03:12 -0400
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Alexey Melnikov <aamelnikov@fastmail.fm>
References: <20160421102401.19578.54300.idtracker@ietfa.amsl.com> <1461412191.851961.587365345.53A5CC4C@webmail.messagingengine.com> <571B634F.9070600@cs.tcd.ie>
From: "Asmus Freytag (c)" <asmusf@ix.netcom.com>
Message-ID: <571BB8EF.4050300@ix.netcom.com>
Date: Sat, 23 Apr 2016 11:03:27 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <571B634F.9070600@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="------------080101030401040800040805"
X-ELNK-Trace: 464f085de979d7246f36dc87813833b2b484d7840976cb7efeb7d878a7a093847441937c07b0e435350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 71.212.2.16
Archived-At: <http://mailarchive.ietf.org/arch/msg/lager/oe0sRcCP4ZTSqa5_Lignvd4AAiA>
Cc: draft-ietf-lager-specification@ietf.org, audric.schiltknecht@viagenie.ca, The IESG <iesg@ietf.org>, lager@ietf.org
Subject: Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT)
X-BeenThere: lager@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Label Generation Rules <lager.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lager>, <mailto:lager-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lager/>
List-Post: <mailto:lager@ietf.org>
List-Help: <mailto:lager-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lager>, <mailto:lager-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Apr 2016 18:03:49 -0000

On 4/23/2016 4:58 AM, Stephen Farrell wrote:
>>> >>(1) section 5: this says code points MUST be 4 hex digits.
>>> >>What is s/w supposed to do if it sees only 2 hex digits?
>>> >>Should it ignore the range or char element or fail to process
>>> >>the entire LGR document?
>> >
>> >I don't mind clarifying this, but in general it means that the whole
>> >document is syntactically invalid and thus must be ignored.
> That's a fine answer.

One would expect the schema validator to catch such issues,
>
>> >
>> >I don't think it is very common for IETF documents to specify error
>> >handling when a MUST is violated, but of course it is not prohibited.
> Well, in this case the error might only affect checking some labels
> and not others, so I guess folks may be tempted to use the rest of
> the LGR if the spec doesn't say to fail to load the LGR on such errors.
>

There's no reason to be permissive in this way. The LGR is supposed to 
describe a definite disposition for any label.

A./