[CCAMP] 答复: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

Fatai Zhang <zhangfatai@huawei.com> Fri, 07 December 2012 09:53 UTC

Return-Path: <zhangfatai@huawei.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 166AB21F86F9 for <ccamp@ietfa.amsl.com>; Fri, 7 Dec 2012 01:53:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzwlg2GRNEV7 for <ccamp@ietfa.amsl.com>; Fri, 7 Dec 2012 01:53:17 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 29AA821F86EE for <ccamp@ietf.org>; Fri, 7 Dec 2012 01:53:16 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANO62104; Fri, 07 Dec 2012 09:53:14 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 09:52:40 +0000
Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 09:53:12 +0000
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.142]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Fri, 7 Dec 2012 17:53:05 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Lou Berger <lberger@labn.net>, CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>
Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04
Thread-Index: AQHN1GCn89VnG+Dzoky5NDMQwrwrZg==
Date: Fri, 07 Dec 2012 09:53:04 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF83583E820@SZXEML552-MBX.china.huawei.com>
References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net>
In-Reply-To: <5084A8C0.1010607@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.72.159]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [CCAMP] 答复: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04
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: Fri, 07 Dec 2012 09:53:19 -0000

Hi Lou,

Please see how the LC comments addressed below.





Best Regards

Fatai


-----邮件原件-----
发件人: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 代表 Lou Berger
发送时间: 2012年10月22日 10:01
收件人: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
主题: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

Authors,
	I have the following LC comments:

General comments:

- This document also needs some addition work on conformance language.
I'll try to point out cases in the detailed comments below.

[Fatai] OK. Checked and refined based on your detailed comments. 

- Section 5 essentially defines a new set of traffic parameters.  Given
the changes, why not ask for a new C-TYPE and not worry about [RFC4328]
compatibility/description?

[Fatai] Accepted to have a new C-TYPE and updated the text accordingly. 

Detailed editorial and technical comments:

- Please verify that abbreviations are defined before being used .
There are a number of these.

[Fatai] Went through and updated. 

- Please use a consistent decimal representation (sometimes commas are
used other times periods)

[Fatai] OK. Commas are used.

- the references [G709-v1] and [G709-v3] each actually refer to multiple
documents, each documented needs to have it's own (correct) reference,
i.g., [G709-v1] and [G709-v1a1]. The document text will need to be
revisited to ensure the proper reference is made.

[Fatai] Accepted and used the same approach for framework draft. 
-
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-04.txt
shows there are unresolved nits that need to resolved .  I'm using line
numbers from this url in my subsequent comments.

- Line 2: The document is currently written as if it "Updates" 4328 this
should be identified in the header.

[Fatai] Accepted and updated.

- Line 43: drop "Recent progress in", replace "standardization" with
[G.709-V3]

[Fatai] Accepted and updated.

- Line 45-53.  Drop all starting from "Several..."

[Fatai] Accepted and updated.

- Lines 95-128: Not sure this adds anything.  Should just reference FWK,
INFO, OSPF and drop the rest.

[Fatai] Accepted and updated.

- Section 3.  Perhaps combine with section 1.

[Fatai] Accepted and refined.

- Section 4, lines 208-238.  For future "proofing"/compatibility, I
suggest removing the bandwidths (2.5, 10, 40 Gbps). or changing all the
"i.e."s into "e.g."s.

[Fatai] Accepted and updated.

- Section 5: assuming this is now a new c-type need text for that, as
well as to formally defined the fields/field sizes.

[Fatai] Accepted to have a new C-TYPE and updated the text accordingly.

- Lines 285-287: replace all lines with "The valid Signal Type values
defined in [RFC4328] are updated to be:"

[Fatai] Accepted and updated.

- Lines 309-318.  I found this really hard to understand.  Why not just
call it Tolerance?

[Fatai] Accepted to remove NMC because new C-type is introduced.

- Lines 320-336,338-346 are essentially repeated in sections 5.1 and
5.2, why not move this text into their respective sections?

[Fatai] Accepted and refined the text.

- lines 445-468: Why not just carry "n" directly?

[Fatai] to make it consistent with ODUflex(CBR). 

- Lines 472-482: Suggest replacing all lines with something like:
This section defines the format of the OTN-TDM Generalized Label.

[Fatai] Accepted and updated.

- Line 484: replace "New definition of ODU" with "OTN-TDM"  Switching Type.

[Fatai] Accepted and updated.

- Lines 486-487: Replace lines with "The following is the Generalized
Label format for that MUST be used with the OTN-TDM Switching Type"

[Fatai] Accepted and updated.

- Line 499: "can be figured out locally according to the identifier of"
--> "is identified by"

[Fatai] Accepted and updated.

- Line 562: "number of bit" --> "number of bits". The valid values for
this field are 0, 4 and 8, right?  If so, this should be spelled out.

[Fatai] Accepted and updated.

- Line 576: "Padded bits" seems off, how about "Pad bits" or "Padding",
also bits aren't represented in label format (line 494)., also "behind"
--> "after"

[Fatai] Accepted and updated.

- Lines 580-588: I suspect these lines should be in a procedures
section, as there should be specific processing rules governing the
described usage.

[Fatai] Accepted and modified accordingly.

Section 6.2: I like the examples, but IMO they belong at the end of
section 6, not in the middle of the normative language.

[Fatai] Accepted and updated.


- Line 656: Generally the processing rules are presented in sections
titled "Procedures".  It is true that this wasn't the case in rfc4328
(section 4.2). I'd suggest following one of the two existing precedents
rather coming up with a third variant.

[Fatai] Accepted and modified the text for "Procedures".

- Lines 658-660.  The normative language in 4328 isn't actually
presented in the section titled "label distribution procedures" (or
"rules" as section 4.2 is actually titled), so this paragraph doesn't
make sense.  I suggest either (a) defining the full set of required
procedures in this document, or (b) referring to the "required
processing defined in [RFC4328]" and other rfcs as appropriate.

[Fatai] Accepted and updated accordingly.

- Lines 662-667: what about generating upstream, suggested, label set,
etc.  Perhaps you should rephrase much into more general rules.

[Fatai] Accepted and updated accordingly.

- Line 682: by "learn" do you mean "identify"?

[Fatai] Accepted and updated.

- Lines 682-685: Who is this learning/identification accomplished?

[Fatai] Accepted and updated.

- Lines 703-704: If this is the normative section defining requirement
processing, the procedures need to be spelled out for all required cases.

[Fatai] Accepted and updated accordingly.

- Lines 706-707: I think this needs to be rephrased to be clear what
behavior is required for a node to be conformant with this sentence.

[Fatai] Accepted and refined accordingly.

- Lines 711-714: why "SHOULD" vs "MUST"?

[Fatai] Accepted and updated.

- Line 712: By "integrity of the label" do you mean "if the label is
acceptable"?

[Fatai] Yes, and updated.


- Line 725: By "reserved resource" do you mean "indicated resource"?

[Fatai] Yes, and updated.

- Line 726: Does "do not match" mean "inconsistent"?

[Fatai] Yes, and updated.

- Line 730, Drop "As".

[Fatai] Accepted and updated.

- Section 6.4: Missing conformance language.

[Fatai] Went through and updated.

- Lines 758-759: This reads like an informative statement, but includes
conformance language.  How does a node conform?  I suggest rephrasing to
be clear.

[Fatai] Accepted and updated.

- Line 761: Why not just make this a MUST?

[Fatai] Accepted and updated.

- Line 763: "SHOULD" --> "MUST"

[Fatai] Accepted and updated.

- lines 768-779: Should either contain conformance language or pointers
to existing language.

[Fatai] Accepted and updated the language.

- Line 783: Why not MUST?

[Fatai] Accepted and updated.

- Section 9, should also reference 4328 and cover delta in information
and added risks.

[Fatai] Accepted and updated.

- Section 10: This section needs some work.  (I'm assuming your familiar
with rfc5226).

[Fatai] Accepted and updated.

- Is it time to create a "Signal Type" registry?

[Fatai] We are not sure, because no "Signal Types" have been registered in the existing RFCs (like RFC3473, RFC4328..).

That's it on this document.

Lou
-

On 10/8/2012 4:47 PM, Lou Berger wrote:
> This mail begins a two week working group last call on:
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-09
> (Informational)
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-04
> (Informational)
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-03
> (Standards Track)
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-04
> (Standards Track)
> 
> This working group last call ends on October 22.  Comments should be
> sent to the CCAMP mailing list.  Please remember to include the
> technical basis for any comments.
> 
> Please note that we're still missing a few IPR statements, and look
> for these to come in during the LC period.  Any forthcoming publication
> request will be delayed by late IPR statements/disclosures.
> 
> Thank you,
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp