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
- [CCAMP] [Editorial Errata Reported] RFC7139 (3924) RFC Errata System
- Re: [CCAMP] [Editorial Errata Reported] RFC7139 (… Adrian Farrel
- [CCAMP] 答复: [Editorial Errata Reported] RFC7139 (… Fatai Zhang
- [CCAMP] ODUflex error in RFC7139 (3924) Fred Gruman
- Re: [CCAMP] ODUflex error in RFC7139 (3924) Lou Berger
- [CCAMP] [Errata Rejected] RFC7139 (3924) RFC Errata System
- [CCAMP] ODUflex resize question in RFC7139 (3924) Gruman, Fred
- [CCAMP] 答复: ODUflex resize question in RFC7139 (3… Fatai Zhang