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

[Lou Berger <[e-mail]>]

Fatai/Authors,
	Thank you for the mail, and sorry about my delayed response.  BTW
please feel free to continue discussing the remaining open issues on the
list and reaching closure on the list (on specific text/resolutions)
prior to publishing the next rev.

Please see below for inline responses.

On 12/7/2012 4:53 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> Please see how the LC comments addressed below.
> 
> 
> 
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表 Lou Berger
> 发送时间: 2012年10月22日 10:01
> 收件人: CCAMP; [e-mail]
> 主题: [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. 
> 

I think this rev is an improvement, but there's still more work needed.
 I have made some specific comments/suggestions below.

> - 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. 
> 

Okay.

> 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. 

thanks.

> 
> - Please use a consistent decimal representation (sometimes commas are
> used other times periods)
> 
> [Fatai] OK. Commas are used.

great, although a quick skim finds:
s/1,301.683.217/1,301,683.217

> 
> - 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. 

great

> -
> 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 .  

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-05.txt
still shows a warning, notably:

     (Using the creation date from RFC4328, updated by this document, for
     RFC5378 checks: 2005-01-17)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to
grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can
ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.)


> I'm using line
> numbers from this url in my subsequent comments.
> 
[...]

> - Section 3.  Perhaps combine with section 1.
> 
> [Fatai] Accepted and refined.
> 

I don't see where this suggestion was followed, but that's okay, it was
just a suggestion.

[...]
> - 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.

Formal field definitions are missing and need to be added.

Also the draft says:

   Note that the error process on the traffic parameters MUST follow the
   rules defined in Section 6 of [RFC4328].

Given the different fields, shouldn't any OTN-TDM related traffic
parameter processing now be defined in this document?

> 
[...]
> 
> - 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.


I don't see where this suggestion was followed. For example:

287  In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be
288  used together to represent the actual bandwidth of ODUflex, where:

and

323  In case of ODUflex(CBR), the information of Bit_Rate and Tolerance in
324  the ODUflex traffic parameters MUST be used to determine the total
325 number of tributary slots N in the HO ODUk link to be reserved. Here:

> 
> - lines 445-468: Why not just carry "n" directly?
> 
> [Fatai] to make it consistent with ODUflex(CBR). 

Given that the recent decision to have an OTN-TDM specific set of
traffic parameters, doesn't it now make sense to just carry N directly?

[...]

> 
> - Line 576: "Padded bits" seems off, how about "Pad bits" or "Padding",

Again, how about "Pad bits" or "Padding"?

> also bits aren't represented in label format (line 494)., also "behind"
> --> "after"
> 
> [Fatai] Accepted and updated.
> 

[...]

> 
> - 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.
> 

I think section 6.2 still needs a bit of work.

So are there procedures that an ingress must follow?
For example:
- Setting of fields in the label request object, such as the OTN-TDM
Switching Type defined in [OTN-OSPF].

What about the egress, are there any special procedures?

The final three paragraphs of the section introduce upstream behaviors
*after* you've described the downstream behavior without specifics of
the new upstream behavior. As a general rule and in this case in
particular, I really think it would be better to cover procedures in the
following order
 - Ingress
 - Generic upstream
 - Generic downstream
 - Egress

Also, generic statements should not use conformance language,
particularly when more detailed rules/procedures, which include such
language, follow.

If you'd like we can discuss/review details on the list once you have a
proposed revision. (I see a bunch of more minor comments on this
section, but don't think it makes sense to focus on these until the more
major comments are addressed.)

[...]
> 
> - 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.
> 

I'll defer responses to the discussion on prior comment.

> - 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.

WRT lines 624-627, I think you still need additional specificity
differentiate upstream/downstream required behavior. Perhaps something
along the lines of:

    When an upstream node receives a Resv message containing an
    LABEL object with an OTN-TDM label, the node MUST verify that
    the label is acceptable. If the label is not acceptable, the
    node MUST generate a ResvErr message with a "Routing
    problem/Unacceptable label value" indication.  Per [RFC3473],
    the generated ResvErr message MAY include an
    ACCEPTABLE_LABEL_SET object.  With the exception of label
    semantics, Downstream node processing a received ResvErr
    messages and of ACCEPTABLE_LABEL_SET objects is not modified
    by this document.

    Similarly, when a downstream node receives a Path message
    containing an UPSTREAM_LABEL object with an OTN-TDM label,
    the node MUST verify that the label is acceptable. If the
    label is not acceptable, the node MUST generate a PathErr
    message with a "Routing problem/Unacceptable label value"
    indication.  Per [RFC3473], the generated ResvErr message MAY
    include an ACCEPTABLE_LABEL_SET object.  With the exception
    of label semantics, Downstream node processing received
    PathErr messages and of ACCEPTABLE_LABEL_SET objects is not
    modified by this document.

    A received label SHALL be considered unacceptable when one of
    the following cases occurs:

    - The received label doesn't conform with local policy.

    ...

> 
> - Line 730, Drop "As".
> 
> [Fatai] Accepted and updated.
> 
> - Section 6.4: Missing conformance language.
> 
> [Fatai] Went through and updated.

New line 660:   The procedures are similar to section 6 of [RFC6344].

Hereto,  If this is the normative section defining required processing,
the procedures need to be spelled out for all required cases or refer to
specific (and unmodified) procedures to follow in a reference document.
 So either define the processing or say procures defined in <appropriate
reference> are followed.

> 
> - 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.
> 

I think this section should be revised to ensure that the
responsibilities of each type of processing node (ingress, upstream,
downstream, egress) is clear.

I guess, we'll have a thread on this section too...

[...]

> 
> - Section 9, should also reference 4328 and cover delta in information
> and added risks.
> 
> [Fatai] Accepted and updated.

We'll see if this is enough to keep the security reviewers happy...

> 
> - Section 10: This section needs some work.  (I'm assuming your familiar
> with rfc5226).
> 
> [Fatai] Accepted and updated.
> 

Better, but you should at least refer to the existing registries, which
already includes G-PIDs (see
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml)

> - 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..).
> 

I think including a request to establish such a registry in this
document would be useful.  Is anyone up to proposing the requisite text?

Thanks,
Lou


> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>