Re: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS

Julien Meuric <julien.meuric@orange.com> Mon, 13 May 2013 16:33 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1880421F8F07 for <ccamp@ietfa.amsl.com>; Mon, 13 May 2013 09:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB2OaktHVTkn for <ccamp@ietfa.amsl.com>; Mon, 13 May 2013 09:33:17 -0700 (PDT)
Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 82CFB21F8EFC for <ccamp@ietf.org>; Mon, 13 May 2013 09:33:17 -0700 (PDT)
Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2366FA442DD; Mon, 13 May 2013 18:34:59 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 16364A442DC; Mon, 13 May 2013 18:34:59 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 18:33:16 +0200
Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 18:33:13 +0200
Message-ID: <519115C1.9080507@orange.com>
Date: Mon, 13 May 2013 18:33:05 +0200
From: Julien Meuric <julien.meuric@orange.com>
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Lou Berger <lberger@labn.net>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
References: <059.82d98e9dee0226e015a3852ed4c8eece@trac.tools.ietf.org> <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> <5190C777.2090100@labn.net>
In-Reply-To: <5190C777.2090100@labn.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 May 2013 16:33:15.0232 (UTC) FILETIME=[9139BE00:01CE4FF7]
Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" <draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org>, CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2013 16:33:22 -0000

Hi.

On my right, a simple prefix that makes values clear and unambiguous at 
reading time, without the burden of references' context; on my left, 2 
confusing statements that will no more be in mind when reading figures...
I have often heard comments about RFC readability and the needed IETF 
background to understand what is not explicit: 2 more characters per 
figure would be both helpful and harmless.

By the way, the IANA registry about GMPLS makes use of the '0x' prefix: 
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml#gmpls-sig-parameters-8

Regards,

Julien


On 05/13/2013 12:59, Lou Berger wrote:
>> >13.  Identification of hexadecimal representation in G.709 vs decimal in
>> >      GMPLS considerations
>> >
>> >    Encoding in GMPLS foresses the utilization of hexadecimal values
>> >    format "0x" while in the data plane documents, like G.709
>> >    reccomendation, the format usually used is the decimal one (e.g.
>> >    G-PID in RSVP-TE vs Payload Type in G.709).
>> >
> Assuming we go this way: I understand your intent, but I think you're
> actually stating exactly the opposite.  How about, simply:
>
>    Note that the Payload Types (PT) defined in [G709-2012], and repeated
>    in this document, are provided in hexadecimal representation without
>    the commonly used '0x' prefix.