Subject: [CCAMP] 2nd WG Last Call comments on g709-framework (editorial only)

From: Lou Berger <[email-masked]>
Date: Fri, 14 Jun 2013 16:03:28 -0400

Hi,
	The following are comments as part of my LC review of
draft-ietf-ccamp-gmpls-g709-framework-12.  Note that I'm the document
shepherd, see RFC 4858 for more information.

I only have editorial nits, which should be picked up in the next
revision of this document.

The most major comment I have is that 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.

Line numbers in the following comments can be found at
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-g709-framework-12.txt

Line 96: "suite including provision [RFC4328] provides"
 This sentence is broken and should be rephrased.  perhaps you mean
 something like:
  The GMPLS signaling extensions defined in [RFC4328] provide the
  mechanisms for basic GMPLS control of OTN networks based on the 2001
  revision of the G.709 specification.

Line 98/9: this is pretty awkward, how about:
  OLD
  Later revisions of the G.709 specification, i.e., [G709-2012], has
  included some new features
  NEW
  The 2012 revision of the G.709 specification, [G709-2012], includes
  new features

Line 143:
  Does it make sense to mention PPM here? suggest dropping.
  Also need to expand acronym on initial use.

Section 3
  Given the discussion on the signaling document I think it's worth
  adding a few words and a reference to [G7041] in this section.

Line 258:
  s/granularity and/granularity,

Line 272:
  s/the 'new' equipment will/[G709-2012] requires 'new' equipment

Line 273:
  s/if/when

Line 313:
 s/TSs/TS

Lines 388/9:
  I think the terminology "flexible optical connections" is not well
  defined in this context.  Either add a reference or drop the word
  "flexible".

Line 390:
  Add a reference defining 3R.  How about adding ", see [RFC6163] for
  additional information." to the end of the line?

Line 438 & 510:
  Add references for MLN.

Line 571-579:
  Given the documented signaling approach, does it still make sense to
  mention tolerance here?

Line 590:
  What is a TS type, perhaps you mean "TSG"?

Line 598:
  s/in order to setting up/in order to set up

Line 604/5
 OLD
 A new extension object has to be defined
 NEW
 A signaling mechanism must be identified

Line 667:
 s/of TS/of each TS

Line 681
 Suggest dropping "and sufficient" as it is completely unclear what
 this means.

Line 721:
 remove redundant text "either no priorities or"

Lines 752-755:
  I'm not sure what value this paragraph provides as LMP information is
  generally available from the management plane (e.g., configuration).

Line 758
  s/case/cases

Line 761:
  s/the discovering procedure by LMP/discovery via LMP

Line 857:
  Need a reference for "TS auto-negotiation is supported"

That's it,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 14 Jun 2013 16:04:17 -0400

Hi,
	The following are comments as part of my LC review of
draft-ietf-ccamp-otn-g709-info-model-08.  Note that I'm the document
shepherd, see RFC 4858 for more information.

Please see
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-otn-g709-info-model-08.txt
for line numbers used in this message.

The draft needs to be nit free before being passed to the IESG. The
following nits show in the above URL:

  Checking references for intended status: Informational

----------------------------------------------------------------------------

  == Unused Reference: 'RFC3630' is defined on line 831, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5250' is defined on line 853, but no explicit
     reference was found in the text

  == Outdated reference: A later version (-06) exists of
     draft-ietf-ccamp-gmpls-ospf-g709v3-04

  == Outdated reference: A later version (-12) exists of
     draft-ietf-ccamp-gmpls-g709-framework-11

  == Outdated reference: A later version (-09) exists of
     draft-ietf-ccamp-gmpls-signaling-g709v3-05

I also have the following editorial comments:

- From my comments on the framework document: this and the other g709v3

- 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.25/2.5", "1.25Gbps", "1.25 GBps" and "1.25 Gbps".  (I personally
 prefer the final form, but any common form is fine.)

Line 24:
 s/methods/protocols

Lines 88-97: Section 1
  This section is a bit odd in what it says and doesn't say.  How about
  something along the following as a replacement:

  GMPLS routing and signaling, as defined by [RFC4203], [RFC3473] and
  [RFC4328],  provides the mechanisms for basic GMPLS control of OTN
  networks based on the 2001 revision of the G.709 specification.
  The 2012 revision of the G.709 specification, [G709-2012], includes
  new OTN features which are not supported by GMPLS.

  This document provides an evaluation of exiting GMPLS signaling and
  routing protocols against G.709 [G.709-2012] requirements. Background
  information and a framework for the GMPLS protocol extensions need to
  support [G.709-2012] is provided in [OTN-FWK].  Specific routing and
  signaling extensions are defined in [OTN-OSPF] and [OTN-RSVP].

Line 214:
  s/2,5/2.5

Line 257:
  Do you perhaps mean "This distinction" rather than "The
  discrimination"?

Line 292:
  s/r[/[

Line 300:
  AUTOpayloadtype needs a reference

Line 320:
  s/TS size/TSG

Line 322/3:
  I think the 1st sentence cane be dropped (as it really just says
  "On the other side the client TSG is the TSG that is exported towards
  the client layer.")

Line 412:
  s/like/such as

Line 416
 s/his/its

Lines 452-457:
 This paragraph is incomprehensible.  I tried to come up with
 suggested, but failed as I'm not sure what is being made.

Line 461:
 A guess:
 s/so to have a more precise choice capability./to enable precise path
selection

Line 464:
 s/allowed/possible

Section 17.
The choice of which documents are informative and which are normative
seems a bit random.  I'm not too sure what a normative reference really
means in this type of informational document in any case, but clearly
the itu data plane documents should be normative if any references are
identified as such.

That's it,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 14 Jun 2013 16:31:42 -0400

Hi,
	The following are comments as part of my LC review of
draft-ietf-ccamp-gmpls-ospf-g709v3-06.  Note that I'm the document
shepherd, see RFC 4858 for more information.

Please see
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt
for line numbers used in this message.

  Miscellaneous warnings:

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL',
'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is
what you
     mean).

     Found 'MUST not' in this paragraph:

     - Unreserved Bandwidth (32 bits): This field indicates the
     Unreserved Bandwidth at a particular priority level.  This field
MUST be
     set to the bandwidth, in bits/s in IEEE floating point format,
available
     at the indicated Signal Type for a particular priority level.  One
field
     MUST be present for each bit set in the Priority field, and is
ordered to
     match the Priority field. Fields MUST not be present for priority
levels
     that are not indicated in the Priority field.This field is REQUIRED for
     Type 2 (variable container) TLVs, and MUST NOT be used for Type 1 TLVs.

  -- The document date (April 4, 2013) is 71 days in the past.  Is this
     intentional?

  Checking references for intended status: Proposed Standard

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-08) exists of
     draft-ietf-ccamp-otn-g709-info-model-05

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.

- Please be consistent in usage of "Gbps".  Some inconsistent examples:
 "1.25/2.5", "1.25Gps", "1.25 GBps" and "1.25 Gbps".  (I personally
 prefer the final form, but any common form is fine.)

- RFC 4203 uses the field name "Switching Capability-specific
  information" while the document uses "Switch Capability Specific
  Information", so throughout the document please
  s/Switch Capability/Switching Capability

- per RFC4203, fix capitalization when referring to the filed name:
  s/MAX LSP bandwidth/MAX LSP Bandwidth

lines 2-5:
  Shouldn't this document be identified as an update to 4203?

Lines 24-32:
  The Abstract is really in need of a make over.  How about something
  like the following:

   This document describes Open Shortest Path First - Traffic
   Engineering (OSPF-TE) routing protocol extensions to support
   Generalized MPLS (GMPLS) control of Optical Transport Networks
   (OTN) specified in ITU-T Recommendation G.709 as published in 2012.
   It extends mechanisms defined in RFC4203.

Line 102:
   Expand ODU

Lines 105/6:
   Drop "which is being standardized in ITU-T"

Line 107:
   s/the routing process/routing

Lines 108:
   You should mentioned the base OSPF TE document here.  How about:
   s/OSPF-TE/use in GMPLS OSPF-TE as defined in [RFC4203].

Line 115:
  s/The routing/Routing

Line 143-145:
  I think this text reads a bit backwards, it is the need for the ISCD
  that drives the new type/swcap, not the other way around  I also
  suggest adding informative reference to
  draft-ietf-ccamp-swcaps-update, perhaps something like:

  OLD
   This
   leads to the need to define a new Switching Capability value and
   associated new Switching Capability for the Interface Switching
   Capability Descriptor (ISCD).
  NEW
   These capabilities are carried in the Interface Switching
   Capability Descriptor (ISCD) Switching Capability-specific
   information field using formats defined in this document.
   As discussed in [swcaps-update], the use of a technology specific
   Switching Capability-specific information field necessitates
   the definition of a new Switching Capability value and
   associated new Switching Capability.

Line 178:
  Drop "on this traffic card"

Lines 192/3:
  "The TE-Link is referred to as OTUk-TE-Link."
  This term is used just once in the document.  Suggest dropping it.

Lines 193/4:
  Doesn't the TE link for an OTUk physical Link always provide ODUk
  capacity? Either way this text needs to be fixed/clarified.

Lines 196, 206:
  Is this an OTUk or ODUk TE link? You first says the former then the
  latter.  I suspect you mean former, i.e., s/ODUk/OTUk

Line 209/10:
  "Such TE-Links are also termed ODUk-TE-Links."
  This term is used just once in the document.  Suggest dropping it.

Lines 210-212,221:
  ODUj vs ODUk.  Isn't it the case that a multi hop TE link could
  represent either ODUj or ODUk resources?  This isn't clear from the
  current text/usage of ODUj/k.

Line 229:
  s/[RFC4202]/and is defined in [RFC4203]

Lines 249-257:
  The document already says 4203 MUST be followed, so no need to provide
  normative language for 4203-defined behavior.  Specifically:
  s/field MUST be used/field is used
  s/MUST be in/is in

Lines 286/7:
  Isn't this sentence redundant with the prior sentence?  Suggest
  dropping.

Line 291:
  s/OTN ISCD/OTN-TDM ISCD

Line 293/4:
  Types are defined in this document.
  Suggest adding:
   Note that type values are defined in this document and not [RFC3630].

Line 301:
  SCSI acronym not defined.

Line 301,302:
  s/any/each

Line 302:
  To clarify and to add a transition to the next paragraph, I suggest
  adding something along the lines of:
   Each container type is identified by a Signal Type.  Signal Type
   values are defined in [OTN-SIG].

Line 469/470:
   The sentence starting "This field is ..." isn't used consistently
   (i.e., not present for Unreserved ODUj, Unreserved Padding, and
    Maximum LSP Bandwidth).  It should be dropped, or parallel
   statements should be added for the other cases.

Line 1112:
  I think the first sentence is a bit hard to follow.  How about:
  OLD
   This document, as [RFC4203], specifies
  NEW
   This document extends [RFC4203]. As with[RFC4203], it specifies

Line 1133:
 s/Type/Name

Line 1145:
 How about the following as the registry name:
   "Types for sub-TLVs of OTN-TDM SCSI (Switch Capability Specific
Information)"

Lines 1153-1159
  To be aligned with what you want to see with the registry, and fix
type 2 description:

  Value		Sub-TLV 			Reference
  0		Reserved 			[This.I-D]
  1             Unreserved Bandwidth    	[This.I-D]
   		for fixed containers
  2             Unreserved/Max Bandwidth 	[This.I-D]
   		for flexible containers
	
Lines 1161/2
  You some parts of the IANA "formula", how about:
  OLD
    New TLV type values may be allocated only by an IETF Consensus
    action.  The request Registration Procedures are Standards Action.
  New
    Types are to be assigned via Standards Action as defined in
    [RFC5226].

Lines 1247-1249:
  Shouldn't [G.709-2012] be normative?

That's it,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 14 Jun 2013 18:15:21 -0400

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:

- 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

---

From: Lou Berger <[email-masked]>
Date: Mon, 17 Jun 2013 06:49:24 -0400

All,

This last call is closed.

Editors, Authors,

Please conclude any discussions related to LC comments received, update
the documents, and then summarize changes to the WG.

Also, in the absence of a response we will need to consider how to
address the following:

> Please note that we're still missing an IPR statement on the 2nd
> draft.  Any forthcoming publication request will be delayed by late
> IPR statements/disclosures.

Thank you!
Lou

On 5/31/2013 12:11 PM, Lou Berger wrote:
> This mail begins a 2nd two week working group last call on:
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-12
> (Informational)
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-08
> (Informational)
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06
> (Standards Track)
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-09
> (Standards Track)
> 
> This working group last call ends on June 16.  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 an IPR statement on the 2nd
> draft.  Any forthcoming publication request will be delayed by late
> IPR statements/disclosures.
> 
> Thank you,
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 19 Jun 2013 01:16:42 +0000

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

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Saturday, June 15, 2013 4:03 AM
To: CCAMP; [email-masked]
Subject: [CCAMP] 2nd WG Last Call comments on g709-framework (editorial only)

Hi,

Line 143:

Section 3

Line 258:

Line 272:

Line 273:
  s/if/when

Line 313:
 s/TSs/TS

Lines 388/9:

Line 390:

Line 438 & 510:
  Add references for MLN.

Line 571-579:

Line 590:

Line 598:

Line 604/5
 OLD

Line 667:
 s/of TS/of each TS

Line 681

Line 721:

Lines 752-755:

Line 758
  s/case/cases

Line 761:

Line 857:

That's it,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 19 Jun 2013 02:06:20 +0000

Hi Lou and all,

Please take a look and any further comments are appreciated.

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Saturday, June 15, 2013 6:15 AM
To: CCAMP; [email-masked]
Subject: [CCAMP] 2nd WG Last Call comments on signaling-g709v3 (editorial only)

Hi,

As with other documents:

Please see

Line 47:

Line 49:

Line 97:

Line 132:
 s/[G.709-V3]/[G709-2012]

Line 143:

Line 330:

Line 373:
 s/PATH/Path

Line 379:
 s/MAY not/may not

Lines 388/9:

Lines 581:

Section 6.

Line 591:
 s/MAY not/need not

Line 611:

Line 624,625,626/7:
  s/TS type/TSG

Line 879.

Lines 888-897
  How about:

   (*) Suggested value

Lines 905-909:
   Drop lines

Line 911->928:

Line 930:

Line 931/932

Line 956:
  add:

Lines 1006-1023:

That's it,
Lou

---

From: "Gruman, Fred" <[email-masked]>
Date: Mon, 24 Jun 2013 13:52:24 +0000

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: [email-masked] [mailto:[email-masked]] 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,

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Saturday, June 15, 2013 6:15 AM
To: CCAMP; [email-masked]
Subject: [CCAMP] 2nd WG Last Call comments on signaling-g709v3 (editorial only)

Hi,

As with other documents:

Please see

Line 47:

Line 49:

Line 97:

Line 132:
 s/[G.709-V3]/[G709-2012]

Line 143:

Line 330:

Line 373:
 s/PATH/Path

Line 379:
 s/MAY not/may not

Lines 388/9:

Lines 581:

Section 6.

Line 591:
 s/MAY not/need not

Line 611:

Line 624,625,626/7:
  s/TS type/TSG

Line 879.

Lines 888-897
  How about:

   (*) Suggested value

Lines 905-909:
   Drop lines

Line 911->928:

Line 930:

Line 931/932

Line 956:
  add:

Lines 1006-1023:

That's it,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 25 Jun 2013 01:22:26 +0000

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:[email-masked]] 
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,

Best Regards,
Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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,

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Saturday, June 15, 2013 6:15 AM
To: CCAMP; [email-masked]
Subject: [CCAMP] 2nd WG Last Call comments on signaling-g709v3 (editorial only)

Hi,

As with other documents:

Please see

Line 47:

Line 49:

Line 97:

Line 132:
 s/[G.709-V3]/[G709-2012]

Line 143:

Line 330:

Line 373:
 s/PATH/Path

Line 379:
 s/MAY not/may not

Lines 388/9:

Lines 581:

Section 6.

Line 591:
 s/MAY not/need not

Line 611:

Line 624,625,626/7:
  s/TS type/TSG

Line 879.

Lines 888-897
  How about:

   (*) Suggested value

Lines 905-909:
   Drop lines

Line 911->928:

Line 930:

Line 931/932

Line 956:
  add:

Lines 1006-1023:

That's it,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Jun 2013 13:58:27 -0400

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

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 26 Jun 2013 00:48:11 +0000

Hi Lou,

Thanks, recorded, I will fix it in the next revision.

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
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,

or in the long form:

OLD

Fred,
	Does this work for you?

Lou

---

From: "Gruman, Fred" <[email-masked]>
Date: Wed, 26 Jun 2013 01:49:33 +0000

Yes, this is fine with me. 

Fred

Sent from my iPad

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 27 Jun 2013 08:46:20 +0000

Hi Lou,

all comments have been addressed, just some minor comments:

1. TS granularity and 1.25/2.5Gbps aligned with other IDs
2. Lines 452-457 dropped as issue already explained in lines 401-409.

BR
Daniele & Sergio

________________________________________
Da: [email-masked] [[email-masked]] per conto di Lou Berger [[email-masked]]
Inviato: venerdì 14 giugno 2013 22.04
A: CCAMP; [email-masked]
Oggetto: [CCAMP] 2nd WG Last Call comments on g709-info-model (editorial)

Hi,

Please see

Line 24:
 s/methods/protocols

Lines 88-97: Section 1

Line 214:
  s/2,5/2.5

Line 257:

Line 292:
  s/r[/[

Line 300:

Line 320:
  s/TS size/TSG

Line 322/3:

Line 412:
  s/like/such as

Line 416
 s/his/its

Lines 452-457:

Line 461:
 A guess:

Line 464:
 s/allowed/possible

Section 17.

That's it,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Jun 2013 12:48:54 -0400

Fatai,
	When do you expect to have this submitted?

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Jun 2013 12:59:42 -0400

Daniele,
	Thank you the changes look good!

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Sun, 30 Jun 2013 17:27:55 +0000

Hi Lou,

I have changed the text in my local document, but I am not sure if it is necessary to submit a new version for this minor editorial change this time.

How about I provide a new revision to address this comment and IESG comments together during IESG review ( I think there must be some comments from IESG review stage)?

Anyway, I think I will certainly defer to your (WG chairs') preference, so your guidance is appreciated. 

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]] 
发送时间: 2013年6月29日 0:49
收件人: Fatai Zhang
抄送: Gruman, Fred; CCAMP
主题: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt

Fatai,

Thanks,
Lou

On 6/25/2013 8:48 PM, Fatai Zhang wrote:
> Subject: Re: [CCAMP] I-D Action: 
> draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt
> 
> Fatai,
>> Subject: RE: [CCAMP] I-D Action: 
>> draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt
>>
>> Hello Fatai,
>>
>> Subject: Re: [CCAMP] I-D Action: 
>> draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt
>>
>> Hi Lou and all,
>>
>> 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.
>>
>>  "1.25Gps", "1.25 Gbps" and "1.25 Gbps".  (I personally  prefer the 
>> final form, but any common form is fine.)
>>
>> Please see
>>  How about adding to the beginning of the paragraph something along 
>> the lines of: