Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

From: Lou Berger <[email-masked]>
Date: Mon, 11 May 2015 09:03:56 -0400

All,
    Per below, I've been asked to call consensus on this, but there
haven't yet been any comments received during the LC period -- which
ends today.  So it's not too late to voice your opinion.

If you can, please review the latest rev of the document and comment. 
Positive comments, e.g., "I've reviewed the latest version of this
document and believe it is ready for publication", are welcome! This
would be helpful, even from authors.  (Just saying "support" without
review doesn't really serve the purpose.)

Thanks,
Lou -- as consensus caller "stuckee"

PS  I have reviewed this rev of the document and believe it is ready for
publication.

On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote:
>
> Working group,
>
>  
>
> this starts a two weeks working group last call on
> draft-ietf-ccamp-flexi-grid-fwk-03.
>
> The last call end on Monday May 11^th . Please send you comments to
> the CCAMP mailing list.
>
>  
>
> All the IPR declarations from authors and contributors have been
> collected and can be found in the history of the document:
> https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/
>
> Please note that no IPR was disclosed against this draft.
>
>  
>
> *_PLEASE NOTE_*
>
> 1.       Since both the chairs and the secretary are involved in the
> draft as co-authors, the consensus will be called by Lou.
>
> 2.       This is a good opportunity to have the WG involved also in
> the Post-WG Last call process nominating a document shepherd which is
> not one of the chairs or the secretary. The document shepherd:
>
> a.       MUST NOT be one of the authors/contributors of the draft
>
> b.      SHOULD be an expert of the ID subject
>
> c.       Will receive all the needed support from the chairs.
>
>  
>
> Further details on the shepherd duties can be found in RFC4858 and at
> https://www.ietf.org/iesg/statement/document-shepherds.html:
>
> Please volunteer if interested
>
>  
>
> Thanks
>
> Daniele & Fatai
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 11 May 2015 13:49:58 -0400

Lou,

As one of the hundred or so :-) contributors to this draft, I've reviewed
the latest version and believe it is ready for publication.

Cheers,
Andy

On Mon, May 11, 2015 at 9:03 AM, Lou Berger <[email-masked]> wrote:

> haven't yet been any comments received during the LC period -- which ends
> today.  So it's not too late to voice your opinion.
>
> Positive comments, e.g., "I've reviewed the latest version of this document
> and believe it is ready for publication", are welcome! This would be
> helpful, even from authors.  (Just saying "support" without review doesn't
> really serve the purpose.)
>
> Thanks,
> The last call end on Monday May 11th. Please send you comments to the
> CCAMP mailing list.
>
>
>
> All the IPR declarations from authors and contributors have been collected
> and can be found in the history of the document:
> *PLEASE NOTE*
> 2.       This is a good opportunity to have the WG involved also in the
> Post-WG Last call process nominating a document shepherd which is not one
> of the chairs or the secretary. The document shepherd:
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 11 May 2015 22:04:03 +0100

Yes, I too reviewed this document before the authors requested last call. My review resulted in some updates in the current version which I now think is ready for publication.
 
Adrian (contributor)
 
From: CCAMP [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: 11 May 2015 18:50
To: Lou Berger
Cc: CCAMP ([email-masked])
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd
 
Lou,
 
As one of the hundred or so :-) contributors to this draft, I've reviewed the latest version and believe it is ready for publication.
 
Cheers,
Andy

On Mon, May 11, 2015 at 9:03 AM, Lou Berger <[email-masked]> wrote:
All,
    Per below, I've been asked to call consensus on this, but there haven't yet been any comments received during the LC period -- which ends today.  So it's not too late to voice your opinion.

If you can, please review the latest rev of the document and comment.  Positive comments, e.g., "I've reviewed the latest version of this document and believe it is ready for publication", are welcome! This would be helpful, even from authors.  (Just saying "support" without review doesn't really serve the purpose.)

Thanks,

PS  I have reviewed this rev of the document and believe it is ready for publication.

this starts a two weeks working group last call on draft-ietf-ccamp-flexi-grid-fwk-03.
The last call end on Monday May 11th. Please send you comments to the CCAMP mailing list.
 
All the IPR declarations from authors and contributors have been collected and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/
Please note that no IPR was disclosed against this draft.
 
PLEASE NOTE
1.       Since both the chairs and the secretary are involved in the draft as co-authors, the consensus will be called by Lou. 
2.       This is a good opportunity to have the WG involved also in the Post-WG Last call process nominating a document shepherd which is not one of the chairs or the secretary. The document shepherd:
a.       MUST NOT be one of the authors/contributors of the draft
b.      SHOULD be an expert of the ID subject
c.       Will receive all the needed support from the chairs.
 
Further details on the shepherd duties can be found in RFC4858 and at https://www.ietf.org/iesg/statement/document-shepherds.html:
Please volunteer if interested
 
Thanks
Daniele & Fatai

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Mon, 11 May 2015 22:02:41 +0000

All,

I've reviewed this revision of the document, and I think it's almost ready for publication. I have a few comments (below) but I don't think there's any major issues.

3.1: definition of OTN could be moved up to section 2.2, if you want.

3.2.1: you state that the Nominal Central Frequency Granularity is 6.25GHz, but there's no reference for this. I assume it's in an ITU doc somewhere? If so, it'd be good to say so (and where)

The document refers to "OTSi signals" in several places, but the definition of "OTSi" includes "signal" :) I don't know whether or not this is normal usage or whether it's worth fixing... but it looks technically wrong to me (like people talking about "PIN numbers" whenever they get cash out of the bank).

3.2.5, first bullet: "This group of OTSi should be carried over a single fibre." Is that a normal English should, or a 2219 SHOULD? If the former, it might be worth rephrasing to avoid ambiguity.

4.2: "The association of the three components a filter, a fiber, and a filter, is a media channel in its most basic form.". It'd be nice to clarify that this is a fiber with a filter at each end - that's not immediately obvious on first reading, especially with the diagram that makes it clear on the next page.

The paragraph below figure 8 is... unclear. Is it just trying to say that media channels can be joined together to make a new media channel? Or is there more to it than that?

Fig 12: OTSi trail? Did you mean OCh trail?

Fig 14: MLN/MRN needs explaining. Or removing.

4.3, towards the end: "there must be enough guard band between adjacent OTSis in any media channel to compensate filter concatenation effect and other effects caused by signal layer switching elements". Maybe "...to compensate for the filter concatenation effect and..." or "...to compensate for filter concatenation effects and..."?

4.8.4: bear in mind that 0 is not a positive integer, and it looks like the definitions involving (2^n) and (2^m) are intended to include the case where n/m is 0.

Cheers

Matt

From: CCAMP [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Monday, May 11, 2015 9:04 AM
To: CCAMP ([email-masked])
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

All,

Thanks,

PLEASE NOTE

Thanks

Daniele & Fatai

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 12 May 2015 01:12:03 +0000

Hi, Lou, all,

I've reviewed the latest version of this document and comments (no major ones) have already sent to Ramon. Thus, I think it is ready for publications.

BTW, if it might be helpful, I can dig out the email and resend the comments to the list.

Regards,
Xian

Sent: 2015年5月11日 21:04

All,

Thanks,

PLEASE NOTE

Thanks

Daniele & Fatai

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 May 2015 08:56:38 +0100

Hello Matt,
 
Leaving the bulk of the editorials to the, erm, editors...
 
> 3.2.5, first bullet: “This group of OTSi should be carried over a single fibre.” Is that
> a normal English should, or a 2219 SHOULD? If the former, it might be worth 
> rephrasing to avoid ambiguity.
 
It is certainly not 2119 because we do not define data plane behaviour.
 
I would favour s/should be/are/
 
> 4.2: “The association of the three components a filter, a fiber, and a filter, is a 
> media channel in its most basic form.”. It’d be nice to clarify that this is a fiber 
> with a filter at each end – that’s not immediately obvious on first reading, 
> especially with the diagram that makes it clear on the next page.
 
s/association/association sequence/
 
> 4.8.4: bear in mind that 0 is not a positive integer, and it looks like the definitions 
> involving (2^n) and (2^m) are intended to include the case where n/m is 0.
 
Yeah, we should probably say "non-negative integer" to be consistent with the usage in computer science.
It would be OK to write ℕ0 if only we supported unicode and superscript in I-Ds :-)
Or perhaps being more explicit "the set of zero and all positive integers".
 
Thanks for the review,
Adrian

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Tue, 12 May 2015 17:12:56 +0000

Adrian,

The alternatives you’ve proposed all sound good to me.

Cheers

Matt

Hello Matt,

Thanks for the review,

Adrian

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 14 May 2015 11:21:56 +0200

Dear Matt, all

Thank you very much for the review and comments, please see inline 
(aligned with Adrian's reply).

For what is worth, there were some comments that I received post LC, 
that will also be in next updated version.

El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribió:
>
> All,
>
> I’ve reviewed this revision of the document, and I think it’s almost 
> ready for publication. I have a few comments (below) but I don’t think 
> there’s any major issues.
>
Ramon> Added as acronym, and removed the expansion, thank you
>
> 3.2.1: you state that the Nominal Central Frequency Granularity is 
> 6.25GHz, but there’s no reference for this. I assume it’s in an ITU 
> doc somewhere? If so, it’d be good to say so (and where)
>
Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1]
>
> The document refers to “OTSi signals” in several places, but the 
> definition of “OTSi” includes “signal” :) I don’t know whether or not 
> this is normal usage or whether it’s worth fixing… but it looks 
> technically wrong to me (like people talking about “PIN numbers” 
> whenever they get cash out of the bank).
>
Ramon> changed OTSi signals to OTSi

> 3.2.5, first bullet: “This group of OTSi should be carried over a 
> single fibre.” Is that a normal English should, or a 2219 SHOULD? If 
> the former, it might be worth rephrasing to avoid ambiguity.
>
Ramon> changed to "are" as per Adrian's suggestion
>
> 4.2: “The association of the three components a filter, a fiber, and a 
> filter, is a media channel in its most basic form.”. It’d be nice to 
> clarify that this is a fiber with a filter at each end – that’s not 
> immediately obvious on first reading, especially with the diagram that 
> makes it clear on the next page.
>
Ramon> Likewise, changed to "association sequence"

> The paragraph below figure 8 is... unclear. Is it just trying to say 
> that media channels can be joined together to make a new media 
> channel? Or is there more to it than that?
>
Ramon> Basically the intent is that one, although it should reflect more 
to the join of "basic" media channels (defined as an association 
sequence of filter-fiber-filter as above). This, and the architectural 
construct being an LSP.  Changed to also use the term "association sequence"

OLD

    Additionally, when a cross-connect for a specific frequency slot is
    considered, the underlying media support is still a media channel,
    augmented, so to speak, with a bigger association of media elements
    and a resulting effective slot.  When this media channel is the
    result of the association of basic media channels and media layer
    matrix cross-connects, this architectural construct can be
    represented as (i.e., corresponds to) a Label Switched Path (LSP)
    from a control plane perspective.  In other words, It is possible to
    "concatenate" several media channels (e.g., Patch on intermediate
    nodes) to create a single media channel.

NEW

    Additionally, when a cross-connect for a specific frequency slot is
    considered, the resulting media support of joining basic media channels
    is still a media channel, i.e., a longer association sequence of media
    elements and its effective frequency slot. In other words, It is possible to
    "concatenate" several media channels (e.g., patch on intermediate
    nodes) to create a single media channel.

    The architectural construct resulting of the association sequence
    of basic media channels and media layer matrix cross-connects can be
    represented as (i.e., corresponds to) a Label Switched Path (LSP)
    from a control plane perspective.

> Fig 12: OTSi trail? Did you mean OCh trail?
Ramon> The error comes from the text, since the correct term is OTSi.

OLD

    In Figure 12 a Network Media Channel is represented as terminated at
    the DWDM side of the transponder.  This is commonly named as OCh-
    trail connection.

NEW

    In Figure 12 a Network Media Channel is represented as terminated at
    the network side of the transponders.  This is commonly named as OTSi-
    trail connection.

> Fig 14: MLN/MRN needs explaining. Or removing.
Ramon> Removed.
>
> 4.3, towards the end: “there must be enough guard band between 
> adjacent OTSis in any media channel to compensate filter concatenation 
> effect and other effects caused by signal layer switching elements”. 
> Maybe “…to compensate for the filter concatenation effect and…” or 
> “…to compensate for filter concatenation effects and…”?
>
Ramon> new text
"there must be  enough guard band between adjacent OTSis in any media 
channel to  compensate for the filter concatenation effects and other 
effects caused by signal layer switching elements"

> 4.8.4: bear in mind that 0 is not a positive integer, and it looks 
> like the definitions involving (2^n) and (2^m) are intended to include 
> the case where n/m is 0.
>
Ramon> Changed for "n" to say "non-negative integer". For "m", I am 
leaving it as positive integer, since m=0 would imply an empty frequency 
slot.

If no further comments, I will proceed to upload these changes for -04 
(with other backlogged changes such as affiliation changes, CCAMP WG, 
Informational, nits, editorial changes , typos, etc. ). Please see the 
attached diff

Thanks
Ramon

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Thu, 14 May 2015 14:29:50 +0000

Thanks, Ramon.

Changes look good to me!

Cheers

Matt

From: CCAMP [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: Thursday, May 14, 2015 5:22 AM
To: [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Dear Matt, all

Thank you very much for the review and comments, please see inline (aligned with Adrian's reply).

For what is worth, there were some comments that I received post LC, that will also be in next updated version.

Ramon> Basically the intent is that one, although it should reflect more to the join of "basic" media channels (defined as an association sequence of filter-fiber-filter as above). This, and the architectural construct being an LSP.  Changed to also use the term "association sequence"

OLD

NEW

OLD

   trail connection.

NEW

   trail connection.

Ramon> new text
"there must be  enough guard band between adjacent OTSis in any media channel to  compensate for the filter concatenation effects and other effects caused by signal layer switching elements"

4.8.4: bear in mind that 0 is not a positive integer, and it looks like the definitions involving (2^n) and (2^m) are intended to include the case where n/m is 0.
Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving it as positive integer, since m=0 would imply an empty frequency slot.

If no further comments, I will proceed to upload these changes for -04 (with other backlogged changes such as affiliation changes, CCAMP WG, Informational, nits, editorial changes , typos, etc. ). Please see the attached diff

Thanks
Ramon

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 May 2015 15:55:35 -0400

All,
    I believe there has been sufficient time and support to indicate
that this document is ready to move forward, i.e., as "consensus caller"
I believe there is WG consensus behind publishing the document.  That
said, there were a few comments that were received during and (per
Ramon) after Monday.  I'd expect the authors to work with those making
the comments, the WG, and the document Shepherd (who, per normal
process, does the actual publication request) to ensure that the
comments are addressed.

Lou

---

From: Huub van Helvoort <[email-masked]>
Date: Sat, 16 May 2015 11:12:44 +0200

Hello Lou,

Please excuse me for the late response (I was in extremely hot
Andalucia this week)

As one of the many contributors to this draft, I reviewed the
most recent version, and comments and I believe it is ready for publication.

Cheers, Huub.

On 14-05-15 16:29, Matt Hartley (mhartley) wrote:
> Thanks, Ramon.
>
> Changes look good to me!
>
> Cheers
>
> Matt
>
> *From:*CCAMP [mailto:[email-masked]] *On Behalf Of *Ramon Casellas
> *Sent:* Thursday, May 14, 2015 5:22 AM
> *To:* [email-masked]
> *Subject:* Re: [CCAMP] WG Last Call on
> draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd
>
> Dear Matt, all
>
>     ready for publication. I have a few comments (below) but I don’t
>     think there’s any major issues.
>
> 6.25GHz, but there’s no reference for this. I assume it’s in an ITU doc
> somewhere? If so, it’d be good to say so (and where)
>
> 3.2.5, first bullet: “This group of OTSi should be carried over a single
> fibre.” Is that a normal English should, or a 2219 SHOULD? If the
> former, it might be worth rephrasing to avoid ambiguity.
>
> that media channels can be joined together to make a new media channel?
> Or is there more to it than that?
>
> 4.3, towards the end: “there must be enough guard band between adjacent
> OTSis in any media channel to compensate filter concatenation effect and
> other effects caused by signal layer switching elements”. Maybe “…to
> compensate for the filter concatenation effect and…” or “…to compensate
> for filter concatenation effects and…”?
>
> Ramon> new text
> 4.8.4: bear in mind that 0 is not a positive integer, and it looks like
> the definitions involving (2^n) and (2^m) are intended to include the
> case where n/m is 0.
>

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 18 May 2015 10:23:28 +0200

El 15/05/2015 a las 21:55, Lou Berger escribió:
> that this document is ready to move forward, i.e., as "consensus 
> caller" I believe there is WG consensus behind publishing the 
> document.  That said, there were a few comments that were received 
> during and (per Ramon) after Monday.  I'd expect the authors to work 
> with those making the comments, the WG, and the document Shepherd 
> (who, per normal process, does the actual publication request) to 
> ensure that the comments are addressed.
>
Dear Lou, all

Version -04 has been uploaded with all comments received so far.

Thanks
Ramon

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 19 May 2015 17:28:56 +0000

Many thanks to Ramon for the addressing the comments, to Lou for helping us with the consensus call and to the many volunteers for being the shepherd of the draft.

Matt Hartley will be the shepherd and we'll proceed with the publication request.

Thanks
Daniele & Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: lunedì 18 maggio 2015 10:23
To: [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

El 15/05/2015 a las 21:55, Lou Berger escribió:
All,
    I believe there has been sufficient time and support to indicate that this document is ready to move forward, i.e., as "consensus caller" I believe there is WG consensus behind publishing the document.  That said, there were a few comments that were received during and (per Ramon) after Monday.  I'd expect the authors to work with those making the comments, the WG, and the document Shepherd (who, per normal process, does the actual publication request) to ensure that the comments are addressed.
Dear Lou, all

Thanks
Ramon

---

From: Jonas Mårtensson <[email-masked]>
Date: Wed, 20 May 2015 07:29:21 +0000

Hi Ramon,

How do you figure that? Doesn't

<Available Slot Width Granularity> ::= (2^m) x 12.5GHz

imply that the available SWGs start at 25 GHz if "m" is positive integer?

/Jonas

From: CCAMP [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: den 14 maj 2015 11:22
To: [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Dear Matt, all

OLD

NEW

OLD

   trail connection.

NEW

   trail connection.

Ramon> new text

Thanks
Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 20 May 2015 10:03:18 +0200

El 20/05/2015 a las 9:29, Jonas Mårtensson escribió:
> leaving it as positive integer, since m=0 would imply an empty 
> frequency slot.
>
> How do you figure that? Doesn’t
>
> imply that the available SWGs start at 25 GHz if “m” is positive integer?
>

Hi Jonas,

True, I think you spotted an error; in any case there is significant 
room for confusion, and now I regret that the model in section 4.8.4 
uses "n" and "m" mixing the ITU-T definitions and the variables in the 
formulas themselves to describe granularities.

- The parameter m is defined by ITU G.694.1 "a slot width defined by: 
12.5 × m where m is a positive integer and 12.5 is the slot width 
granularity in GHz."
- The parameter n is defined 193.1 + n × 0.00625 where n is a positive 
or negative integer including  0, parameter to describe nominal central 
frequencies (for which n can be indeed negative).
- Unfortunately both are used to describe granularities in the model and 
are not the same concepts.

In the formulas, both are ok using 0.
I would suggest this (using p and q). IMHO, we will need to upload a -05 
asap.

    <Available Central Frequency Granularity> ::= (2^p) x 6.25GHz
      where p is a non negative integer, giving rise to granularities
      such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz

    <Available Slot Width Granularity> ::= (2^q) x 12.5GHz
      where q is a non negative integer

In other words, I guess that the text before latest changes was ok, 
barred the unfortunate choice of names. But I would like to request for 
comments on this. Or maybe I am making things worse :)

R.

> *Sent:* den 14 maj 2015 11:22
> *To:* [email-masked]
>     I’ve reviewed this revision of the document, and I think it’s
>     almost ready for publication. I have a few comments (below) but I
>     don’t think there’s any major issues.
>
> Ramon> Basically the intent is that one, although it should reflect 
> more to the join of "basic" media channels (defined as an association 
> leaving it as positive integer, since m=0 would imply an empty 
> frequency slot.
>
>

---

From: Jonas Mårtensson <[email-masked]>
Date: Wed, 20 May 2015 08:52:24 +0000

"In other words, I guess that the text before latest changes was ok, barred the unfortunate choice of names. But I would like to request for comments on this. Or maybe I am making things worse :)"

Older versions had:

<Available Central Frequency Granularity> ::= n x 6.25GHz

<Available Slot Width Granularity> ::= m x 12.5GHz

In -03 it was instead:

<Available Central Frequency Granularity> ::= (2^n) x 6.25GHz

i.e. "n" and "m" were changed to "2^n" and "2^m" but it still said that "n" and "m" were positive integers which is wrong. The new formulas (even if n,m = 0 is included) also change the available granularities but I assume this was intended (I was not involved).

Anyway, I agree with your suggestion to use different parameter names (p and q) for specifying granularities to reduce risk for confusion.

/Jonas

From: Ramon Casellas [mailto:[email-masked]]
Sent: den 20 maj 2015 10:03
To: Jonas Mårtensson; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Hi Jonas,

True, I think you spotted an error; in any case there is significant room for confusion, and now I regret that the model in section 4.8.4 uses "n" and "m" mixing the ITU-T definitions and the variables in the formulas themselves to describe granularities.

- The parameter m is defined by ITU G.694.1 "a slot width defined by: 12.5 × m where m is a positive integer and 12.5 is the slot width granularity in GHz."
- The parameter n is defined 193.1 + n × 0.00625 where n is a positive or negative integer including  0, parameter to describe nominal central frequencies (for which n can be indeed negative).
- Unfortunately both are used to describe granularities in the model and are not the same concepts.

In the formulas, both are ok using 0.
I would suggest this (using p and q). IMHO, we will need to upload a -05 asap.

In other words, I guess that the text before latest changes was ok, barred the unfortunate choice of names. But I would like to request for comments on this. Or maybe I am making things worse :)

R.

/Jonas

From: CCAMP [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: den 14 maj 2015 11:22
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Dear Matt, all

OLD

NEW

OLD

   trail connection.

NEW

   trail connection.

Ramon> new text

Thanks
Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 20 May 2015 12:26:47 +0200

> i.e. “n” and “m” were changed to “2^n” and “2^m” but it still said 
> that “n” and “m” were positive integers which is wrong. The new 
> formulas (even if n,m = 0 is included) also change the available 
> granularities but I assume this was intended (I was not involved).
Jonas, all

Let's try to re-visit this again and come up with some definitive text. 
I also wonder about:

* the need to introduce formulas or similar o just provide a list of 
acceptable values.
* whether a single value captures the intended model attribute (e.g. 
granularity is X) or multiple values are acceptable.

IMHO: we should ideally list the acceptable values and capture common 
deployments, rather than exotic configurations such as "this node only 
supports ncf of 6.25 if between this frequency and that frequency and 25 
otherwise, or it can support width granulaties of x,y,z depending on ...)

ITU rec is not extremely helpful, and only provides main guidelines: 
ITU-T Rec G.694.1 ( http://www.itu.int/rec/T-REC-G.694.1-201202-I/en ) 
states Appendix I: /"The flexible DWDM grid defined in clause 7 has a 
nominal central frequency granularity of 6.25 GHz and a slot width 
granularity of 12.5 GHz. However, devices or applications that make use 
of the flexible grid may not have to be capable of supporting every 
possible slot width or position. In other words, applications may be 
defined where only a subset of the possible slot widths and positions 
are required to be supported. For example, an application could be 
defined where the nominal central frequency granularity is 12.5 GHz (by 
only requiring values of n that are even) and that only requires slot 
widths as a multiple of 25 GHz (by only requiring values of m that are 
even)."/

For nominal central frequency granularity
=========================================
we had:

A) <Available Central Frequency Granularity> ::= p x 6.25GHz
B) <Available Central Frequency Granularity> ::= (2^p) x 6.25GHz for p>=0

Typically, values used for this (in fixed grid)  "/The frequency grid 
defined by this Recommendation supports a variety of fixed channel 
spacings ranging from 12.5 GHz to 100 GHz and wider (integer multiples 
of 100 GHz) as well as a flexible grid. Uneven channel spacings using 
the fixed grids are also allowed./" Note that in section 6, values with 
n=0 are used as reference for all the grids. IOW, we are implying that 
the granularity is given wrt n=0.

A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that 
are not necessarily common or deployed.
B) yields 6.25, 12.5, 50.0, 100, 200, 400... it fails to capture the 
"integer multiples of 100",

Questions:
Q1: should we cover values above 100/200 ? if yes, B) fails.
Q2: do we need to explictly mention that granularity itself is not 
enough without mentioning a "reference/anchor" NCF that is not n=0? do 
we assume that n=0 is always available and the granularity is always wrt 
to it -- relying on the " <Available Frequency Range-List> " to complete 
this information?"

For nominal central frequency granularity
=========================================
we had :
C)<Available Slot Width Granularity> ::= q x 12.5GHz
D) <Available Slot Width Granularity> ::= (2^q) x 12.5GHz q>= 0

C) yields 12.5, 25, 37.5, 50, 62.5, 75
D) yields  12.5, 25, 50, 100, 200, 400,

D) is excluding restrictions such as "frequency slots with m=3 (37.5 
GHz)" so I am not sure it is ok if we want to cover those. It seems 
safer to stick to C) imho

For available frequency range
==========================================
In -03, -04

    <Available Frequency Range> ::=
      ( <Start Spectrum Position> <End Spectrum Position> ) |
      <Sets of contiguous slices>

I don't like neither the use of "position" nor the use of the undefined 
term "slice"

Proposed text
=====================

<Available Central Frequency Granularity> ::=
     A value from within the list 6.25GHz, 12.5GHz, 25GHz, 50GHz, 100GHz, 200GHz, 300GHz, 400GHz...
     -- Note that the granularity is defined with respect to anchor frequency given by n=0

<Available Slot Width Granularity> ::=
     A value from within the list defined byq x 12.5GHz  where q is a positive integer (q>0)
     -- It is the minimum slot width that can be defined

<Available Frequency Range> ::=
      ( <Start Nominal Central Frequency> <End Nominal Central Frequency> ) |
        <A frequency slot defined by its n and m contaning a set of contiguous nominal central frequencies>

Any comments? Yes/no? suggested alternatives?  much appreciated :)

Thanks

Ramon

---

From: Jonas Mårtensson <[email-masked]>
Date: Wed, 20 May 2015 12:51:13 +0000

"A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are not necessarily common or deployed."

Still... I don't really see a good reason why you would exclude those values (which are compliant with G.694.1) at this point... More generally, I think an information model should describe the needed information, not necessarily limit values representing the information (that could be done in a future encoding draft).

Anyway, and sorry if I confuse things even more, it seems to me that what you actually want to capture with the information model is available center frequencies and slot widths, not the granularities per se. Granularities are one way to represent available values but how to represent those could be left for a future encoding draft. So a more general information model could be:

<Available Spectrum> ::=
       <Available Frequency Range-List>
       <Available Central Frequencies>
       <Available Slot Widths>

<Available Central Frequencies> ::= the subset of supported n values (where n is defined as in G.694.1)

<Available Slot Widths> ::= the subset of supported m values (where m is defined as in G.694.1)

If you want to go one step further and limit how to represent these subsets by introducing granularities (and possibly offsets but that is maybe unnecessarily complex) you could have:

<Available Central Frequencies> ::=
        <Available Central Frequency Granularity>
        <Offset>

One possible representation would be to say that available center frequencies are the subset of supported n values given by p x n + q where p (granularity) is a positive integer and q (offset) belongs to 0,..,q-1.

<Available Slot Widths> ::=
        <Available Slot Width Granularity>
        <Min Slot Width>
        <Max Slot Width>

/Jonas

From: Ramon Casellas [mailto:[email-masked]]
Sent: den 20 maj 2015 12:27
To: Jonas Mårtensson; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Let's try to re-visit this again and come up with some definitive text. I also wonder about:

* the need to introduce formulas or similar o just provide a list of acceptable values.
* whether a single value captures the intended model attribute (e.g. granularity is X) or multiple values are acceptable.

IMHO: we should ideally list the acceptable values and capture common deployments, rather than exotic configurations such as "this node only supports ncf of 6.25 if between this frequency and that frequency and 25 otherwise, or it can support width granulaties of x,y,z depending on ...)

ITU rec is not extremely helpful, and only provides main guidelines: ITU-T Rec G.694.1 ( http://www.itu.int/rec/T-REC-G.694.1-201202-I/en ) states Appendix I: "The flexible DWDM grid defined in clause 7 has a nominal central frequency granularity of 6.25 GHz and a slot width granularity of 12.5 GHz. However, devices or applications that make use of the flexible grid may not have to be capable of supporting every possible slot width or position. In other words, applications may be defined where only a subset of the possible slot widths and positions are required to be supported. For example, an application could be defined where the nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and that only requires slot widths as a multiple of 25 GHz (by only requiring values of m that are even)."

Typically, values used for this (in fixed grid)  "The frequency grid defined by this Recommendation supports a variety of fixed channel spacings ranging from 12.5 GHz to 100 GHz and wider (integer multiples of 100 GHz) as well as a flexible grid. Uneven channel spacings using the fixed grids are also allowed." Note that in section 6, values with n=0 are used as reference for all the grids. IOW, we are implying that the granularity is given wrt n=0.

A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are not necessarily common or deployed.
B) yields 6.25, 12.5, 50.0, 100, 200, 400... it fails to capture the "integer multiples of 100",

Questions:
Q1: should we cover values above 100/200 ? if yes, B) fails.
Q2: do we need to explictly mention that granularity itself is not enough without mentioning a "reference/anchor" NCF that is not n=0? do we assume that n=0 is always available and the granularity is always wrt to it -- relying on the " <Available Frequency Range-List> " to complete this information?"

For nominal central frequency granularity
=========================================
we had :
C) <Available Slot Width Granularity> ::= q x 12.5GHz
D) <Available Slot Width Granularity> ::= (2^q) x 12.5GHz q>= 0

D) is excluding restrictions such as "frequency slots with m=3 (37.5 GHz)" so I am not sure it is ok if we want to cover those. It seems safer to stick to C) imho

I don't like neither the use of "position" nor the use of the undefined term "slice"

Proposed text
=====================

    A value from within the list defined by q x 12.5GHz where q is a positive integer (q>0)

Thanks

Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 20 May 2015 15:37:53 +0200

Jonas, all

Thanks for your careful review of the IM. Please see inline

El 20/05/2015 a las 14:51, Jonas Mårtensson escribió:
>
> A)<Available Central Frequency Granularity> ::= p x 6.25GHz
>
> ”A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values 
> that are not necessarily common or deployed.”
>
> Still… I don’t really see a good reason why you would exclude those 
> values (which are compliant with G.694.1) at this point… More 
> generally, I think an information model should describe the needed 
> information, not necessarily limit values representing the information 
> (that could be done in a future encoding draft).
>

Ramon> good point. I guess we do not need to necessarily list the actual 
values themselves, and exclude compliant ones.

> Anyway, and sorry if I confuse things even more, it seems to me that 
> what you actually want to capture with the information model is 
> available center frequencies and slot widths, not the granularities 
> per se. Granularities are one way to represent available values but 
> how to represent those could be left for a future encoding draft. So a 
> more general information model could be:
>
> <Available Spectrum> ::=
>
Ramon> It is true that I have been thinking whether the information on 
NCF granularity could be implied by its (dynamic) availability, and 
whether we were adding redundancy (e.g. those NCFs that are not 
supported by reasons of granularity would never appear as available e.g. 
in  <Available Frequency Range-List>). On a second thought, this seems 
to not be always the case (only when the choice of formats is chosen to 
be so). It seems perfectly valid to list both the available ranges e.g. 
by means of start/end and then which NCFs are possible/available, so +1 
to your suggestion. See below once integrated

> If you want to go one step further and limit how to represent these 
> subsets by introducing granularities (and possibly offsets but that is 
> maybe unnecessarily complex) you could have:
>
> One possible representation would be to say that available center 
> frequencies are the subset of supported n values given by p x n + q 
> where p (granularity) is a positive integer and q (offset) belongs to 
> 0,..,q-1.
>
Ramon> I understand q (offset) belongs to 0,.., p-1, right? but ok.

Ramon> In order to try to complete it, Would the following be ok ?

OLD

    <Available Spectrum> ::=
        <Available Frequency Range-List>
        <Available Central Frequency Granularity >
        <Available Slot Width Granularity>
        <Minimal Slot Width>
        <Maximal Slot Width>

    <Available Frequency Range-List> ::=
        <Available Frequency Range> [<Available Frequency Range-List>]

    <Available Central Frequency Granularity> ::= (2^n) x 6.25GHz
      where n is a non negative integer, giving rise to granularities
      such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz

    <Available Slot Width Granularity> ::= (2^m) x 12.5GHz
      where m is positive integer

    <Minimal Slot Width> ::= j x 12.5GHz,
      j is a positive integer

    <Maximal Slot Width> ::= k x 12.5GHz,
        k is a positive integer (k >= j)

NEW

       NCF: Nominal Central Frequency

    <Available Spectrum> ::=

        <Available NCFs>

        <Available Slot Widths>

where

    <Available Frequency Range-List> ::=
        <Available Frequency Range> [<Available Frequency Range-List>]

    <Available Frequency Range> ::=
      ( <Start NCF> <End NCF> ) |
        <FS defined by its (n, m) and containing a set of contiguous available NCFs>

and

    <Available NCFs> ::=
         <Available NCF Granularity> [<Offset>]
    -- Subset of supported n values given by p x n + q where p is a positive integer and q (offset) belongs to 0,..,p-1.

and
    <Available Slot Widths> ::=
         <Available Slot Width Granularity>
         <Min Slot Width>
          -- value given by j x 12.5GHz, with j a positive integer
         <Max Slot Width>
          -- value given by k x 12.5, with k a positive integer (k >= j)

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 20 May 2015 15:07:13 +0000

Ramon,

A couple more things.

Is this doc informational or standards-track? It claims to be informational, but it has RFC 2119 language in it.

Also, it's missing the standard boilerplate for this stuff:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

Should that be added?

Also: you currently have six main authors, and my understanding is that the RFC Editor's guidelines are that there should be no more than five....

Cheers

Matt

Thanks
Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 20 May 2015 19:06:49 +0200

Dear Matt,

Please see inline

El 20/05/2015 a las 17:07, Matt Hartley (mhartley) escribió:
>
> Ramon,
>
> Is this doc informational or standards-track? It claims to be 
> informational, but it has RFC 2119 language in it.
It is a good question, which has been popping frequently during the 
lifetime of the draft. The last indication I received (internally) was 
that it should be informational, and I changed it. I guess the problem 
is that as a fwk document is mainly informational, but at some point in 
the distant past, it was decided to include also control plane 
requirements (I guess those are the sections that use RFC 2119 
language). Maybe wiser people can comment on this, but it was my 
(admittedly limited) understanding that those are non-exclusive (i.e., 
RFCs may be informational but yet define requirements and use RFC2119 
language to indicate requirement levels, adding the appropriate 
boilerplate).

Also, it’s missing the standard boilerplate for this stuff:

Uhm, afaik, it is not (I just checked both in -03 and -04 and the 
boilerplate is there $2.1). The change standards track -> informational 
happened in -04.

In any case, no objection either way. I will proceed with whatever 
option is more appropriate

> Also: you currently have six main authors, and my understanding is 
> that the RFC Editor’s guidelines are that there should be no more than 
> five….
>
Thanks for pointing this out, we were told of this not so long ago,...
I would like to ask whether five is a rigid limit and whether exceptions 
may be granted (consider this a not-so-subtle request for exception...), 
given that this draft was the result of merging several drafts -- which 
explains the amazingly long list of contributors -- and authorship was a 
quite hard thing to agree on. OTOH I guess that if this policy really 
needs to be enforced, we will have to find a way (hopefully not 
involving dice)

Thanks for your feedback
Ramon

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 20 May 2015 17:11:55 +0000

Thanks, Ramon.

Hopefully the chairs and other knowledgeable folks can chime in on the 2119 language vs informational stuff.

Apologies on the requirements boilerplate – I just didn’t scroll down far enough :)

Cheers

Matt

Dear Matt,

Please see inline

Is this doc informational or standards-track? It claims to be informational, but it has RFC 2119 language in it.
It is a good question, which has been popping frequently during the lifetime of the draft. The last indication I received (internally) was that it should be informational, and I changed it. I guess the problem is that as a fwk document is mainly informational, but at some point in the distant past, it was decided to include also control plane requirements (I guess those are the sections that use RFC 2119 language). Maybe wiser people can comment on this, but it was my (admittedly limited) understanding that those are non-exclusive (i.e., RFCs may be informational but yet define requirements and use RFC2119 language to indicate requirement levels, adding the appropriate boilerplate).

Uhm, afaik, it is not (I just checked both in -03 and -04 and the boilerplate is there $2.1). The change standards track -> informational happened in -04.

In any case, no objection either way. I will proceed with whatever option is more appropriate

Also: you currently have six main authors, and my understanding is that the RFC Editor’s guidelines are that there should be no more than five….
Thanks for pointing this out, we were told of this not so long ago,...
I would like to ask whether five is a rigid limit and whether exceptions may be granted (consider this a not-so-subtle request for exception...), given that this draft was the result of merging several drafts -- which explains the amazingly long list of contributors -- and authorship was a quite hard thing to agree on. OTOH I guess that if this policy really needs to be enforced, we will have to find a way (hopefully not involving dice)

Thanks for your feedback
Ramon

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 21 May 2015 07:57:57 +0000

Hi Matt, Ramon,

Since I found no clear statements on the usage of RFC2119 language with respect to this situations, I had a look at existing framework and requirement RFCs trying to find a common WoW. My take is:

-          Framework is always informational

-          Requirements are always informational

-          RFC2119 language is not homogeneous. Sometimes capital letters are used and sometimes not.

My preference is to use capital letters only when protocol behavior is defined, not when requirements for the design of the protocol are defined (this is in line with e.g. RFC7062 and RFC6163).
As I said this is just a preference, but if there is no reasonable objection I would suggest not to use any capital letter in the fwk+req document.

Thanks
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of Matt Hartley (mhartley)
Sent: mercoledì 20 maggio 2015 19:12
To: Ramon Casellas; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Thanks, Ramon.

Cheers

Matt

Dear Matt,

Please see inline

Thanks for your feedback
Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 21 May 2015 10:20:19 +0200

El 21/05/2015 a las 9:57, Daniele Ceccarelli escribió:
>
> Hi Matt, Ramon,
>
> Since I found no clear statements on the usage of RFC2119 language 
> with respect to this situations, I had a look at existing framework 
> and requirement RFCs trying to find a common WoW. My take is:
>
> -Framework is always informational
>
> -Requirements are always informational
>
> -RFC2119 language is not homogeneous. Sometimes capital letters are 
> used and sometimes not.
>
> My preference is to use capital letters only when protocol behavior is 
> defined, not when requirements for the design of the protocol are 
> defined (this is in line with e.g. RFC7062 and RFC6163).
>
> As I said this is just a preference, but if there is no reasonable 
> objection I would suggest not to use any capital letter in the fwk+req 
> document.
>
>
Hi Daniele, all

  I was also checking existing RFCs, and IMHO:
- The document can stay informational, it is mainly fwk+reqs. We seem to 
agree on this.
- While RFC2119 states "In many standards track documents several words 
are used to signify the requirements in the specification", there seems 
to  be (some?) existing practice on using RFC2119 wording in reqs/info 
documents, including capitalization.
- Usage of RFC2119 keywords seems scoped to the section on requirements 
in the draft. It could be argued that defining requirements is to some 
extent defining high level protocol behavior :)

IIRC Adrian authored a significant part of the section, any views?

That said, -05 needs to be uploaded anyway to reflect the new info-model 
(thanks Jonas!) , it is not game-changing to change to acomodate what 
you suggest. We could remove RFC2119 reference, the boilerplate text and 
re-visit the sections, mainly using lowercase.

Thanks
R.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 21 May 2015 08:25:49 +0000

Hi Ramon,

No worries, the last call comments can be solved in two different version, we can send the -05 to the IESG (if there are no major changes from -03 to -05).

Yes, I’d like to hear from Adrian on the requirements section.

Thanks
Daniele

From: Ramon Casellas [mailto:[email-masked]]
Sent: giovedì 21 maggio 2015 10:20
To: Daniele Ceccarelli; Matt Hartley (mhartley); [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Hi Daniele, all

 I was also checking existing RFCs, and IMHO:
- The document can stay informational, it is mainly fwk+reqs. We seem to agree on this.
- While RFC2119 states "In many standards track documents several words are used to signify the requirements in the specification", there seems to  be (some?) existing practice on using RFC2119 wording in reqs/info documents, including capitalization.
- Usage of RFC2119 keywords seems scoped to the section on requirements in the draft. It could be argued that defining requirements is to some extent defining high level protocol behavior :)

That said, -05 needs to be uploaded anyway to reflect the new info-model (thanks Jonas!) , it is not game-changing to change to acomodate what you suggest. We could remove RFC2119 reference, the boilerplate text and re-visit the sections, mainly using lowercase.

Thanks
R.

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Thu, 21 May 2015 08:42:48 +0000

My understanding is the same what Daniele summarized and I second the proposal below.

RFC7062 provides a good reference. Without using RFC2119 language, It includes optional and compulsory requirements to GMPLS protocols (OSPF-TE, RSVP-TE, LMP).

Regards,
Xian

From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: 2015年5月21日 15:58
To: Matt Hartley (mhartley); Ramon Casellas; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Hi Matt, Ramon,

Thanks
Daniele

Thanks, Ramon.

Cheers

Matt

Dear Matt,

Please see inline

Thanks for your feedback
Ramon

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 21 May 2015 08:57:02 +0000

Hi all,
I would like to share the experience in RFC7062, which also describes a set of requirments in Section 5.
If my memory is correct, I as the editor of RFC7062 was asked by Lou (as the CCAMP chair at that time)  to remove RFC2119 language during the LC of this draft.
I would also like to hear the confirmation from Adrian and our AD, Deborah.

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, May 21, 2015 4:26 PM
To: Ramon Casellas; Matt Hartley (mhartley); [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Hi Ramon,

Thanks
Daniele

From: Ramon Casellas [mailto:[email-masked]]
Sent: giovedì 21 maggio 2015 10:20
To: Daniele Ceccarelli; Matt Hartley (mhartley); [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Hi Daniele, all

Thanks
R.

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 May 2015 08:40:10 -0400

On 05/21/2015 04:57 AM, Fatai Zhang wrote:
>   If my memory is correct, I as the editor of RFC7062 was asked by Lou
>   (as the CCAMP chair at that time)  to remove RFC2119 language during
>   the LC of this draft.

Sounds right.  In general RFC 2119 conformance language is only
appropriate when discussing things that can impact interoperability,
formats and behavior "on the wire". This is a general rule, and their
are exceptions...

Lou

> *From:*CCAMP [mailto:[email-masked]] *On Behalf Of *Daniele
> Ceccarelli
> *Sent:* Thursday, May 21, 2015 4:26 PM
> *To:* Ramon Casellas; Matt Hartley (mhartley); [email-masked]
> No worries, the last call comments can be solved in two different
> version, we can send the -05 to the IESG (if there are no major changes
> from -03 to -05).
> 
>  
> 
> *From:*Ramon Casellas [mailto:[email-masked]]
> *Sent:* giovedì 21 maggio 2015 10:20
> *To:* Daniele Ceccarelli; Matt Hartley (mhartley); [email-masked]
> <mailto:[email-masked]>
>     My preference is to use capital letters only when protocol behavior
>     is defined, not when requirements for the design of the protocol are
>     objection I would suggest not to use any capital letter in the
>     fwk+req document.
> 
>      
> 
> Hi Daniele, all
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 21 May 2015 16:33:03 +0100

I'm not going to get excited about this.

I was pretty much OK with Standards Track in -03. I thought that the document
told folk how build a network as well as setting the requirements. So in -03 the
2119 language was fine, IMHO.

However, if we want to go Informational I also don't mind. Clearly 2119 language
is less relevant in an informational document, although I often find it is
helpful in requirements specs to clarify the requirements. I have handled this
in the past by using a variation of the 2119 boilerplate such as in section 2 of
https://www.rfc-editor.org/rfc/rfc5862.txt (completely random example).

But I really, really don't care. path of least resistance to raid publication,
please.

Adrian

> -----Original Message-----
> Sent: 21 May 2015 13:40
> To: Fatai Zhang; Daniele Ceccarelli; Ramon Casellas; Matt Hartley (mhartley);
> [email-masked]
> Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and
call
> for sheperd

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 21 May 2015 15:42:22 +0000

Hi all,

There is no "correct way" as you all have noted. Quickly looking at examples, when we did RFC4139, we did use RFC2119 language but that was important as it was reflecting ITU-T requirements. It's really up to the working group. Reading the draft, I don't see an overuse of it, and the authors seem to have thought carefully on it. So it may help as start doing the protocol work.

So...it really is up to you. If keep, you may want to put a couple of sentences as in RFC4139 (section 2) on the use of RFC2119 language in an informational document.

On another comment - you do need to have only 5 names on the front page. There are many ways to do it (e.g. only have the editor(s) on the front page).

Thanks,
Deborah

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, May 21, 2015 8:40 AM
To: Fatai Zhang; Daniele Ceccarelli; Ramon Casellas; Matt Hartley (mhartley); [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Lou

> Yes, I'd like to hear from Adrian on the requirements section.
> 
>  
> 
> Thanks
> 
> Daniele
> 
>  
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 May 2015 11:51:05 -0400

I don't have a strong opinion on this either way for this draft.  My
statement was WRT Fatai's comment on RFC7062 and the general usage of
2119 language.

Lou

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 21 May 2015 21:08:27 +0200

All

Thank you very much for stating your opinions. In view of the circulated 
examples, I will proceed to add extra text to qualify the use of RFC2119 
language. Since we were given the choice, I think that this approach 
minimizes the number of edits and changes, is less error prone and does 
not require sub-sub-subsequent review of the sections (even if a 
:%s/MUST/must/cg could do it...)

OTOH no one has objected to the new IM following Jonas' comments. I will 
leave a few more days and update these two changes in a -05 version

I have contacted the authors privately to follow RFC editor guidelines 
regarding authorship.

Regards
Ramon