Re: [CCAMP] [Editorial Errata Reported] RFC7139 (3924)

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 22 March 2014 14:38 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53BF1A072D for <ccamp@ietfa.amsl.com>; Sat, 22 Mar 2014 07:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.783
X-Spam-Level:
X-Spam-Status: No, score=-99.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=no
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 HpVPgFqWQZxX for <ccamp@ietfa.amsl.com>; Sat, 22 Mar 2014 07:38:32 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7721A06E0 for <ccamp@ietf.org>; Sat, 22 Mar 2014 07:38:32 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2MEcLb1001818; Sat, 22 Mar 2014 14:38:21 GMT
Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2MEcHdd001796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Mar 2014 14:38:18 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <zhangfatai@huawei.com>
References: <20140321030515.3EF087FC387@rfc-editor.org>
In-Reply-To: <20140321030515.3EF087FC387@rfc-editor.org>
Date: Sat, 22 Mar 2014 14:38:18 -0000
Message-ID: <0a6b01cf45dc$60228370$20678a50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHOa01ZFCUWCPLrd3NQLBCwFhjCkpru3JBA
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20582.007
X-TM-AS-Result: No--21.828-10.0-31-10
X-imss-scan-details: No--21.828-10.0-31-10
X-TMASE-MatchedRID: UuaOI1zLN1gwJ6xbTjBa5vp1plqEbuqxVX7TxgU0dK7FpA1uJFd1mkPI vIQWz+36j/rlY8pxdQZAcvaeVJmUzjurH0qx1kBY4bl1FkKDELcUkWvaqUqLH1Xzges/EJ9s9Dj F1GESGA/N/ORHZSvsGY4MgaOHQWe2SbMo2JpgK/TmAId+2bAQwrd2noO4P7rALraGNlLRahiy1V qa24VemRleVjeIL4waZOasGGCiFjj51WNA1rE6t1Pjo7D4SFg4GPx27R2NrHsz91mDYZLM5ca2D 3Ql1MAU0ic5nN68VGWHUIRbbD806/OwxZF760LnwCZxkTHxccnUZrYvzuo9Apps2hiiMFB2/eqo Ab5G2DT5Swo+HknGyWXe2kAh1Tz0TX7PJ/OU3vL+xOhjarOnHrHlqZYrZqdI+gtHj7OwNO0CpgE TeT0ynA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/Xm6OTurtb8mip6n8j_9x4AD6-R4
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] [Editorial Errata Reported] RFC7139 (3924)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Sat, 22 Mar 2014 14:38:35 -0000

Hi Fatai,

I'm having trouble understanding the report.

RFC 4328 shows the value 5 as "reserved (for future use)." This is the
equivalent of the IANA tag "Unassigned".

RFC 7139 creates the "OTN Signal Type" registry and includes the value 5 as
Unassigned.

I don't find any other mention of the value 5 in RFC 7139, so I don't understand
how this value is being specially treated. In particular, I don't find any
mention in the table of Signal Types in section 5.

Also, I don't understand the meaning of "Reserved (for G.709)". Does it mean
that the G.709 Recommendation can make a code point allocation? Does it mean
that a future update of RFC 7139 might want to request allocation of this value
for a very specific purpose and so it would be bad to allocate it for something
else?

And lastly, given that these are OTN signal types, and given that OTN is defined
in G.709, why would this value need special reservation treatment "for G.709"?

I'm inclined to reject your Errata Report, but want to give you a chance to
clarify.

Thanks,
Adrian

> -----Original Message-----
> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> Sent: 21 March 2014 03:05
> To: zhangfatai@huawei.com; zhangguoying@mail.ritt.com.cn;
> sergio.belotti@alcatel-lucent.it; daniele.ceccarelli@ericsson.com;
> kpithewan@infinera.com; akatlas@gmail.com; adrian@olddog.co.uk;
> lberger@labn.net; dbrungard@att.com
> Cc: zhangfatai@huawei.com; ccamp@ietf.org; rfc-editor@rfc-editor.org
> Subject: [Editorial Errata Reported] RFC7139 (3924)
> 
> The following errata report has been submitted for RFC7139,
> "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport
> Networks".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7139&eid=3924
> 
> --------------------------------------
> Type: Editorial
> Reported by: Fatai Zhang <zhangfatai@huawei.com>
> 
> Section: 11
> 
> Original Text
> -------------
> 5        Unassigned                            [RFC4328]
> 
> 
> Corrected Text
> --------------
> 5       Reserved (for G.709)                  [RFC7139]
> 
> Notes
> -----
> (1)Unassigned->Reserved (for G.709)
> (2)[RFC4328]->[RFC7139]
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC7139 (draft-ietf-ccamp-gmpls-signaling-g709v3-12)
> --------------------------------------
> Title               : GMPLS Signaling Extensions for Control of Evolving G.709
Optical
> Transport Networks
> Publication Date    : March 2014
> Author(s)           : F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli, K.
Pithewan
> Category            : PROPOSED STANDARD
> Source              : Common Control and Measurement Plane
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG