Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt

["Gruman, Fred" <[e-mail]>]

Yes, this is fine with me. 

Fred

Sent from my iPad

On Jun 25, 2013, at 7:58 PM, "Fatai Zhang" <[e-mail]> wrote:

> Hi Lou,
> 
> Thanks, recorded, I will fix it in the next revision.
> 
> 
> 
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Wednesday, June 26, 2013 1:58 AM
> To: Fatai Zhang
> Cc: Gruman, Fred; CCAMP
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt
> 
> Fatai,
>    I think both my and Fred's comments can be addressed by the following:
> s/(2.5Gbps, +/-100ppm)/2.5Gbps
> s/no longer/not
> 
> or in the long form:
> 
> OLD
>   As shown in Figure 1, assume there is an ODUflex(CBR) service
>   requesting a bandwidth of (2.5Gbps, +/-100ppm) from node A to node C.
>   In other words, the ODUflex Traffic Parameters indicate that Signal
>   Type is 20 (ODUflex(CBR)), Bit_Rate is 2.5Gbps (Note that the
>   tolerance is no longer signaled as explained above).
> NEW
>   As shown in Figure 1, assume there is an ODUflex(CBR) service
>   requesting a bandwidth of 2.5Gbps from node A to node C.
>   In other words, the ODUflex Traffic Parameters indicate that Signal
>   Type is 20 (ODUflex(CBR)), Bit_Rate is 2.5Gbps (Note that the
>   tolerance is not signaled as explained above).
> 
> Fred,
>    Does this work for you?
> 
> Lou
> 
> On 6/24/2013 9:22 PM, Fatai Zhang wrote:
>> Hi Fred,
>> 
>> I added this sentence because of a comment from Lou (It is "Tolerance no longer signaled. Suggest saying as much").
>> 
>> I am OK to remove this sentence, but I would like to hear from Lou (either remove or refine it).
>> 
>> 
>> 
>> 
>> 
>> 
>> Best Regards
>> 
>> Fatai
>> 
>> -----Original Message-----
>> From: Gruman, Fred [mailto:[e-mail]] 
>> Sent: Monday, June 24, 2013 9:52 PM
>> To: Fatai Zhang; Lou Berger; CCAMP
>> Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt
>> 
>> Hello Fatai,
>> 
>> I have one comment on Section 5.1.  In this section, there is the following text: "Note that the tolerance is no longer signaled as explained above".  
>> 
>> I believe this sentence should be removed as tolerance was never signaled in a published RFC, only in early versions of the G.709 signaling drafts. This may be confusing to the reader once the RFC is published as the context to early drafts is lost.
>> 
>> Best Regards,
>> Fred
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Fatai Zhang
>> Sent: Tuesday, June 18, 2013 9:06 PM
>> To: Lou Berger; CCAMP
>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt
>> 
>> Hi Lou and all,
>> 
>> A new version has been submitted to address the 2nd WG Last Call comments on this draft.
>> 
>> Please take a look and any further comments are appreciated.
>> 
>> 
>> 
>> 
>> Best Regards
>> 
>> Fatai
>> 
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Lou Berger
>> Sent: Saturday, June 15, 2013 6:15 AM
>> To: CCAMP; [e-mail]
>> Subject: [CCAMP] 2nd WG Last Call comments on signaling-g709v3 (editorial only)
>> 
>> Hi,
>>    The following are comments as part of my LC review of
>> draft-ietf-ccamp-gmpls-signaling-g709v3-09.  Note that I'm the document
>> shepherd, see RFC 4858 for more information.
>> 
>> As with other documents:
>> - This and the other g709v3 documents should be consistent in usage of
>> "TS granularity" versus "TSG".  Sometimes one is used rather than the
>> other, sometimes both are used in the same document (as is the case in
>> this document).  Please pick either one and update the four documents to
>> be consistent.
>> 
>> - Another and related comment is please define and use a consistent
>> plural form of "TS".  You initially define "TSs" to expand to "Time
>> Slots", but then use "TS" as the plural form in many (but not all
>> cases).  I personally think "TSs" in all plural cases makes the most sense.
>> 
>> - Also same comment for TSGs.
>> 
>> - Please be consistent in usage of "Gbps".  Some inconsistent examples:
>> "1.25Gps", "1.25 Gbps" and "1.25 Gbps".  (I personally
>> prefer the final form, but any common form is fine.)
>> 
>> Please see
>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-09.txt
>> for line numbers used in this message.
>> 
>> Line 47:
>> s/updates/provides an alternative to
>> 
>> Line 49:
>> s/evolving OTN addressing ODUk multiplexing and new/full set of OTN
>> 
>> Line 97:
>> s/updates/provides an alternative to
>> 
>> Line 132:
>> s/[G.709-V3]/[G709-2012]
>> 
>> Line 143:
>> drop "needs to be updated because it"
>> 
>> Line 330:
>> "Here:" what?  Do you mean "Where:"?
>> 
>> Line 373:
>> s/PATH/Path
>> 
>> Line 379:
>> s/MAY not/may not
>> 
>> Lines 388/9:
>> Tolerance no longer signaled.  Suggest saying as much.
>> 
>> Lines 581:
>> s/ignored/ignored on receipt.
>> 
>> Section 6.
>> You should consistently use formal object names throughout this
>> section, which can be found at
>> http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml.
>> e.g, "Label Set" --> "LABEL_SET Object".
>> 
>> Line 591:
>> s/MAY not/need not
>> 
>> Line 611:
>>  As repeating whats in 3473, suggest lower case usage of 2119 terms.
>> 
>> Line 624,625,626/7:
>>  s/TS type/TSG
>> 
>> Line 879.
>> How about adding to the beginning of the paragraph something along the
>> lines of:
>>   This document is a modification to [RFC3473] and [RFC4328], and only
>>   differs in specific information communicated. As such, this document
>>   ...
>> 
>> Lines 888-897
>>  How about:
>>   Upon approval of this document, IANA will make the following
>>   assignments in the "Class Types or C-Types ‒ 9 FLOWSPEC" and
>>   "Class Types or C-Types ‒ 12 SENDER_TSPEC" section of the "RSVP
>>   Parameters" registry located at
>>   http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml
>> 
>>   Value     Description         Reference
>>    7*       OTN-TDM             [This.I-D]
>> 
>>   (*) Suggested value
>> 
>> Lines 905-909:
>>   Drop lines
>> 
>> Line 911->928:
>>  to match registry, Replace with:
>>   Value Type                            Technology       Reference
>>   ===== ======================          ==========
>>   47    G.709 ODU-2.5G                  G.709 ODUk      [RFC4328],
>>         (IANA to update Type field)                     [This.I-D]
>>   56    SBCON/ESCON                     G.709 ODUk,     [RFC4328],
>>         (IANA to update Type field)       Lambda, Fiber [This.I-D]
>>   59*   Framed GFP                      G.709 ODUk      [This.I-D]
>>   60*   STM-1                           G.709 ODUk      [This.I-D]
>>   61*   STM-4                           G.709 ODUk      [This.I-D]
>>   62*   InfiniBand                      G.709 ODUflex   [This.I-D]
>>   63*   SDI (Serial Digital Interface)  G.709 ODUk      [This.I-D]
>>   64*   SDI/1.001                       G.709 ODUk      [This.I-D]
>>   65*   DVB_ASI                         G.709 ODUk      [This.I-D]
>>   66*   G.709 ODU-1.25G                 G.709 ODUk      [This.I-D]
>>   67*   G.709 ODU-Any                   G.709 ODUk      [This.I-D]
>>   68*   Null Test                       G.709 ODUk      [This.I-D]
>>   69*   Random Test                     G.709 ODUk      [This.I-D]
>>   70*   64B/66B GFP-F Ethernet          G.709 ODUk      [This.I-D]
>> 
>> Line 930:
>>  Add "Upon approval of this document, IANA will define a "OTN
>> 
>> Line 931/932
>>  Drop to end of sentence starting with "will be defined by ..."
>> 
>> Line 956:
>>  add:
>>    New values are to be assigned via Standards Action as defined in
>>    [RFC5226].
>> 
>> Lines 1006-1023:
>>  Aren't these all normative references?
>> 
>> That's it,
>> Lou
>> 
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>