Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info

From: Lou Berger <[email-masked]>
Date: Mon, 20 Jan 2014 14:52:51 -0500

Young, (all),

Now that the IPR issues are resolved on the document set, it's time to
get these documents published.

There are few minor items in this document.

On 11/7/2013 5:32 PM, Leeyoung wrote:
> Hi Lou,
> 
> Here's my response to specific comments to draft-ietf-ccamp-rwa-info. 
> 
> Thanks.
> Young
> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]] 
> Sent: Tuesday, October 29, 2013 1:26 PM
> To: CCAMP; [email-masked]
> Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info
> 
> 
...

> 
> YOUNG>> [Switch] moved to normative reference section.

A normative reference to a a journal paper, are you sure?  I would have
just changed the language to make it informative, but it's your call.
(Unless the RFC editor chimes in on it...)

...

> 
> - Section 5: I found it hard to parse the following:
>    As resources are the smallest identifiable unit of
>    processing resource, one can group together resources into blocks if
>    they have similar characteristics relevant to the optical system
>    being modeled, e.g., processing properties, accessibility, etc.
>   Do you perhaps mean?
>    A resource is the smallest identifiable unit of
>    allocation. One can group together resources into blocks if
>    they have similar characteristics relevant to the optical system
>    being modeled, e.g., processing properties, accessibility, etc.
> 
> YOUNG>> Agreed. Changed.

I think you have a bad cut and paste.

s/resource./allocation.

> -Section 5.1: States: " Note that except for <ResourcePoolState>
>   all the other components of <ResourcePool> are relatively static."
>   But the related definitions are:
> 
>    <ResourcePool> ::= <ResourceBlockInfo>...
>    [<ResourceAccessibility>...] [<ResourceWaveConstraints>...]
>    [<RBPoolState>] (section 5)
> 
>    <DynamicNodeInfo> ::=  <NodeID> [<ResourcePoolState>] (section 7.2)
> 
>    What's the intent here?
> 
> YOUNG>> See the cleaned text in Section 7.2:
>    Currently the only node information that can be considered dynamic
>    is the resource pool state and can be isolated into a dynamic node
>    information element as follows:
> 
>    <DynamicNodeInfo> ::=  <NodeID> [<ResourcePool>]
> 
>    Where
> 
>    <ResourcePool> ::= <ResourceBlockInfo>...[<RBPoolState>] 

sorry, I didn't mean for you to incorporate the <ResourcePool>
definition into the document.  this was just for our discussion.  I
don't think adding a duplicate/incomplete definition here is the right
thing.  So I'd drop it (starting with Where.)

> 
> 
> - Section 5.2: What is the asterisk "*" all about.
> 
> YOUNG>> That means whatever within () can be repeated. 
> 

I don't recall this syntax definition in BNF/RBNF. Take a look at
http://tools.ietf.org/html/rfc5511#section-2.2.5.

Also you list [<ResourceSet>] as optional, yet it is mandatory in
section 4.1 of
http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-23

...
> 
> - Section 6.6.  I think you have a BNF problem here.  The BNF says
> restriction parameters are always optional, but your text says that
> there are requirements based on <RestrictionTypes>.  I think the BNF
> needs to be aligned with the text and reflect the requirements.
> 
> YOUNG>> Made all mandatory element. 

The new text says:

   <PortLabelRestriction> ::= <GeneralPortRestrictions>...
   <MatrixSpecificRestrictions>...

This now says that a PortLabelRestriction MUST (and always) include
*both* GeneralPortRestrictions and MatrixSpecificRestrictions.  Is this
correct in all cases?

also:

   <RestrictionParameters> ::= <LabelSet>... <MaxNumChannels>
   <MaxWaveBandWidth>

So all parameters MUST be included for all RestrictionTypes?  I suspect
you mean to say there alternatives based on RestrictionType.  If
correct, syntax is covered in
http://tools.ietf.org/html/rfc5511#section-2.2.4.

Also the RestrictionParameters object/field naming doesn't match
draft-ietf-ccamp-general-constraint-encode-13.txt, this section should
be updated to match.

...
I think this covers all open points on this one.

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 20 Jan 2014 14:53:10 -0500

Young, (all),

You have two idnit issues:
  == Missing Reference: 'RWA-INFO' is mentioned on line 198, but not defined
  == Missing Reference: 'RFC 6205' is mentioned on line 779, but not defined

I have just one question on this one:

> - section 2.2.
>    Labels are variable in lengh and need not be 4 bytes long.  This
>    needs to be represented and accounted for in the encodings defined
>    in this section.
> 
> YOUNG>> Agreed. Added the following sentence in Section 2.6 (new section due to shuffling):
>    "Labels are variable in length. The second 32 bit field is a part of the base label used as a
>    starting point in many of the specific formats."
> 

I don't understand what you mean by the "second 32 bit field" are you
referring to the " Additional fields as necessary per action" field
shown on page 14?

Thanks,

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 20 Jan 2014 14:53:40 -0500

Young, (all),

idnits says:
(see
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-rwa-wson-encode-23.txt)
  == Line 497 has weird spacing: '...(number  of  r...'
  == Missing Reference: 'RWA-INFO' is mentioned on line 154, but not defined
  == Unused Reference: 'RFC2578' is defined on line 1248, but no explicit
     reference was found in the text

On 11/12/2013 9:06 PM, Leeyoung wrote:
> Hi Lou,
> 
> Please see inline for my responses to your comments. Let me know if there are still further issues. 
> 
> Thanks.
> Young
> 
> Sent: Tuesday, October 29, 2013 1:27 PM
> To: CCAMP; [email-masked]
> Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode
> 
> Authors,
> 	I have some comments on this document. Many are strictly editorial. Note that I'm the document shepherd, see RFC 4858 for more information.
> 
> - Please address my general comments on the WSON document set
> 
> YOUNG>> Done. See Terminology Section changed as follows: 
> 
> Refer to [RFC6163] for CWDM, DWDM, RWA, WDM. 
> Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool.
> 

you now have two section 1s.  Perhaps the second should be 1.1?

...

> - Section 3.1
>     0 1 2 3 4 5 6 7 8
>     | Connectivity  |
>   Why is connectivity a byte here, but only a bit in section 2.1?
>   Either it should be a bit here to, or section 2.1 should be a byte.
>   Note, that this can be fixed in a compatible way by defining it here
>   as:
>     0 1 2 3 4 5 6 7 8
>     |   Reserved  |C|
> 
> YOUNG>> Your suggested encoding accepted. 
> 

I expected that the "C" bit would end up in the same bit location all
things being equal.  The new text has the reserved field of 7 bits, the
corresponding 'action' field is 8 bit's so I think you're one bit too
short.   Either way, you should give the number of bits that are in each
reserved field to make this unambiguous. Perhaps?
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Reserved(8bits)|C|             Reserved  (23 bits)             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> - Section 4.
>   The definitions of sub-sub-TLVs are a bit underspecified.  Some
>   specific questions to address:
> 
>   - Are there any sub-sub-TLV ordering requirements?
> 
> YOUNG>> No.
> 

Where is this stated?  Now that they are list as fields this is even
less self evident.

>   - How are multiple sub-sub-TLVs of the same type to be handled?
> 
> YOUNG>> I don't see why there are multiple sub-sub-TLVs of the same
> type. In case where there are multiple sub-sub-TLVs of the same type,
> there would be no error as these information are not order-sensitive.
> Is this what you have in mind?
> 

Again, just looking for an explicit statement of processing requirements.

>   - What is the sub-sub-TLV header (TL format)?
> 
> YOUNG>> Added TLV format

It looks like only the Optical Interface Class List field has a type and
length field (neither of which are defined).  What about the other 3?
(Acceptable Client Signal Type, Input Bit Rate List, Processing
Capabilities List)

Also, note that you reference the "Processing Capabilities List" but
don't define it.

4.6. is titled "Processing Capability List Field", 4.6.1 is titled
"Processing Capabilities Field" which defines the "processing capability
field".  Clearly you need to pick just one.

> 
>   - Are there any alignment requirements?
> 
> YOUNG>> Not sure what this is. 

It's part of a typical TLV definition.

> 
>   - What happens when a sub-sub-TLV is larger than 256 bytes?
>     (There are already systems that advertise 192 wavelengths on a
>     fiber and an application code takes 8 bytes, right? But
>     of course this presents a problem when carried within an RSVP
>     object too.)
> 
>   If you find you need more specifics, we can discuss / I can propose
>   new text.  Feel free to discuss the details on or off list (your
>   choice.)
> 
> 
> YOUNG>> Please see the other email response to this comment. 
> 
[copied]
> YOUNG>> For the last dash item, "what happens when sub-sub-TLV is
larger than 256 bytes", I guess you meant that the RB Info Field (in
which to contain sub-sub-TLVs) can exceed 256 bytes as opposed to
individual sub-sub-TLVs in the RB Info Field?

It was a general question, as the topic has showed up as a general in in
ccamp. I'd expect it to be addressed as part of the TLV definition.

>
> YOUNG>> As for the resolution for this case, should this be addressed
in the respective routing and signaling drafts?

If it's likely to happen, then I think you need to say something about
it.  If it should never happen, e.g., due to fixed sizes, then it can be
ignored.

> YOUNG>> I am not familiar the method to resolve this kind of issues
--- can you suggest some references or relevant text?  I think this
issue would arise both routing and signaling.

Agreed.  Truncation and semantic fragmentation show up in a bunch of
places. The real question is, is how worried do we need to be about this
case?

...

> 
> - Section 3.4, 4.1
>   - Bits I & E are defined here, but I & O are used in parallel ways in
>     Section 3.2. For consistency it should be I & O everywhere (to
>     match input and output).
> 
> YOUNG>> Corrected to I & O.
> 

You still have one case of an E-bit (rather than O-bit) in Section 4.3.

...

Lou

---

From: Leeyoung <[email-masked]>
Date: Mon, 27 Jan 2014 23:46:57 +0000

Hi Lou,

Here's my comments to your comments. Please see inline for detail. Enclosed is a working draft that reflects all the changes per your comments.
Let me know if this is ready to be published.

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, January 20, 2014 1:53 PM
To: Leeyoung; CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info

Young, (all),

Now that the IPR issues are resolved on the document set, it's time to get these documents published.

...

> YOUNG>> [Switch] moved to normative reference section.

A normative reference to a a journal paper, are you sure?  I would have just changed the language to make it informative, but it's your call.
(Unless the RFC editor chimes in on it...)

...

YOUNG>> It was a mistake I think that took place while I was shifting some references around. I will put [Switch] back to informative reference section. 

s/resource./allocation.

YOUNG>> Agree. Done. "A resource is the smallest... allocation...."

>    <ResourcePool> ::= <ResourceBlockInfo>...[<RBPoolState>]

sorry, I didn't mean for you to incorporate the <ResourcePool> definition into the document.  this was just for our discussion.  I don't think adding a duplicate/incomplete definition here is the right thing.  So I'd drop it (starting with Where.)

YOUNG>> OK. "Where..." is dropped. Also changes in Section 5.1: 
Original: <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> <InAvailableWavelengths> <OutAvailableWavelengths>)...
Changed:  <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> [<InAvailableWavelengths>] [<OutAvailableWavelengths>])*

As <InAvailableWavelengths> <OutAvailableWavelengths> are only used in the cases of shared input or output access to the particular block.

> YOUNG>> That means whatever within () can be repeated. 

I don't recall this syntax definition in BNF/RBNF. Take a look at http://tools.ietf.org/html/rfc5511#section-2.2.5.

YOUNG>> Yes, I replaced "*" with "..." (per 2.2.5) which means 'repetition.' 

Also you list [<ResourceSet>] as optional, yet it is mandatory in section 4.1 of
http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-23

YOUNG>> <ResourceSet> is optional. I don't think section 4.1 of wson-encode-23 treats this as mandatory. Wson-encode-23 document simply provides encoding details irrespective of whether it is mandatory or optional. Let me know if you disagree with this. 

...

The new text says:

This now says that a PortLabelRestriction MUST (and always) include
*both* GeneralPortRestrictions and MatrixSpecificRestrictions.  Is this correct in all cases?

YOUNG>> No. Actually <PortLabelRestriction> is an optional information. It will be corrected as follows:

   <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] [<MatrixSpecificRestrictions>...]
----------------------------------------------------------------------------------------------------
also:

So all parameters MUST be included for all RestrictionTypes?  I suspect you mean to say there alternatives based on RestrictionType.  If correct, syntax is covered in http://tools.ietf.org/html/rfc5511#section-2.2.4.

YOUNG>> No. Indeed these parameters appear only if they match with Restriction Types. So it should be as follows:

<RestrictionParameters> ::= (<LabelSet>...) | <MaxNumChannels> | <MaxLabelRange> | (<LabelSet>... <MaxNumChannels>) | <LinkSet> (Note: this is arranged to be consistent with draft-ietf-ccamp-general-constraint-encode-13.txt in the naming and order)

In Section 6.6, this is a summary of all encoding changes: 

<PortLabelRestriction> ::= [<GeneralPortRestrictions>...] [<MatrixSpecificRestrictions>...]

<GeneralPortRestrictions> ::= <RestrictionType> <RestrictionParameters>  (RestictionType and one of the parameters corresponding to the RestrictionType must be there)

<MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType> <RestrictionParameters> (the same rational apples as above) 

<RestrictionParameters> ::= 
(<LabelSet>...) | <MaxNumChannels> | <MaxLabelRange> | (<LabelSet>... <MaxNumChannels>) | <LinkSet> 

Also the RestrictionParameters object/field naming doesn't match draft-ietf-ccamp-general-constraint-encode-13.txt, this section should be updated to match.

YOUNG>> RestrictionParameters are now matching with draft-ietf-ccamp-general-constraint-encode-13.txt.

s/PortSet/LinkSet
s/MaxWaveWidth/MaxLabelRange

...

Lou

---

From: Leeyoung <[email-masked]>
Date: Tue, 28 Jan 2014 01:04:00 +0000

Hi Lou,

All missing references are added. 

Yes, the "second 32 bit field is referring to "Additional fields as necessary per action" field shown on page 14."

Old: The second 32 bit field is a part of the base label used as a starting point in many of the specific formats.
New: The second 32 bit field (which is referred to by "Additional fields as necessary per action" in the below encoding) is a part of the base label used in many of the specific formats.

Attached is a working version of draft-ietf-ccamp-general-constraint-encode-14.txt. 

Let me know if this is ready to publish.

Regards,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, January 20, 2014 1:53 PM
To: Leeyoung; CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-general-constraint-encode

Young, (all),

>    starting point in many of the specific formats."

I don't understand what you mean by the "second 32 bit field" are you referring to the " Additional fields as necessary per action" field shown on page 14?

Thanks,

Lou

---

From: Leeyoung <[email-masked]>
Date: Tue, 28 Jan 2014 01:04:00 +0000

Hi Lou,

All idinits have been corrected. 

Here's the working document (v.24). Let me know if this is ready for publication.

Regards,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, January 20, 2014 1:54 PM
To: Leeyoung; CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode

Young, (all),

idnits says:
(see

...

> - Section 3.1

I expected that the "C" bit would end up in the same bit location all things being equal.  The new text has the reserved field of 7 bits, the corresponding 'action' field is 8 bit's so I think you're one bit too

>   - Are there any sub-sub-TLV ordering requirements?

Where is this stated?  Now that they are list as fields this is even less self evident.

>   - What is the sub-sub-TLV header (TL format)?

It looks like only the Optical Interface Class List field has a type and length field (neither of which are defined).  What about the other 3?
(Acceptable Client Signal Type, Input Bit Rate List, Processing Capabilities List)

Also, note that you reference the "Processing Capabilities List" but don't define it.

4.6. is titled "Processing Capability List Field", 4.6.1 is titled "Processing Capabilities Field" which defines the "processing capability field".  Clearly you need to pick just one.

[copied]
> YOUNG>> For the last dash item, "what happens when sub-sub-TLV is
larger than 256 bytes", I guess you meant that the RB Info Field (in which to contain sub-sub-TLVs) can exceed 256 bytes as opposed to individual sub-sub-TLVs in the RB Info Field?

It was a general question, as the topic has showed up as a general in in ccamp. I'd expect it to be addressed as part of the TLV definition.

If it's likely to happen, then I think you need to say something about it.  If it should never happen, e.g., due to fixed sizes, then it can be ignored.

> YOUNG>> I am not familiar the method to resolve this kind of issues
--- can you suggest some references or relevant text?  I think this issue would arise both routing and signaling.

Agreed.  Truncation and semantic fragmentation show up in a bunch of places. The real question is, is how worried do we need to be about this case?

...

...

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Jan 2014 17:35:17 -0500

Young,

See below.

> Changed:  <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> [<InAvailableWavelengths>] [<OutAvailableWavelengths>])*

As was the case below, an asterisk isn't valid RBNF, so shouldn't be in
this line.

Also recall that parentheses implies strict ordering. Perhaps you mean:
<RBPoolState> ::= <ResourceBlockID> <NumResourcesInUse> 		
		[<InAvailableWavelengths>] [<OutAvailableWavelengths>]
		[<RBPoolState>]

> YOUNG>> Yes, I replaced "*" with "..." (per 2.2.5) which means 'repetition.' 

So you now have:
   <ResourceBlockInfo> ::= ([<ResourceSet>] <InputConstraints>
   [<ProcessingCapabilities>] <OutputConstraints>)...

That's fine, but keep in mind that use of parenthesis implies ordering.
Do you mean:

   <ResourceBlockInfo> ::= [<ResourceSet>] <InputConstraints>
		   [<ProcessingCapabilities>] <OutputConstraints>
		   [<ResourceBlockInfo>]

Actually since the use of <ResourceBlockInfo> already indicates
repetition in section 5, no  repetition is needed here, which yields

   <ResourceBlockInfo> ::= [<ResourceSet>] <InputConstraints>
		   [<ProcessingCapabilities>] <OutputConstraints>

> YOUNG>> <ResourceSet> is optional. I don't think section 4.1 of wson-encode-23 treats this as mandatory. Wson-encode-23 document simply provides encoding details irrespective of whether it is manda…

So 4.1 of wson-encode-24 you just distributed says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     RB Set Field                              |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|O|                         Reserved                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Optical Interface Class List(s) (opt)          |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Acceptable Client Signal Type (opt)             |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Input Bit Rate List (opt)                  |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Processing Capabilities List (opt)             |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To me, I'd read this as

   <ResourceBlockInfo> ::= <ResourceBlockSet>
		   [<InputConstraints>] [<OutputConstraints>]
		   [<ProcessingCapabilities>]

Which is correct?  Also note that you have ResourceSet in this document
and "RB Set Field" in wson-encode-24. to align this document:
s/<ResourceSet>/<ResourceBlockSet>

>    <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] [<MatrixSpecificRestrictions>...]

A few points here:
1) to get repetition of <PortLabelRestriction> I suggest:
OLD
   <LinkInfo> ::=  <LinkID> [<AdministrativeGroup>]
   [<InterfaceCapDesc>] [<Protection>] [<SRLG>]...
   [<TrafficEngineeringMetric>] [<PortLabelRestriction>]
NEW
   <LinkInfo> ::=  <LinkID> [<AdministrativeGroup>]
   [<InterfaceCapDesc>] [<Protection>] [<SRLG> ...]
   [<TrafficEngineeringMetric>] [<PortLabelRestriction> ...]

2) What is unclear is that when <PortLabelRestriction> what it must
contain.  looking at 2.2 of wson-encode-24 I see

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MatrixID    |RestrictionType| Switching Cap |     Encoding  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Additional Restriction Parameters per RestrictionType     |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

which translates to me to be:
    <PortLabelRestriction> ::= <MatrixID> <RestrictionType>
				<Restriction parameters list>

    <Restriction parameters list> ::=
		<Simple label restriction parameters> |
		<Channel count restriction parameters> |
		<Label range restriction parameters> |
		<Simple+channel restriction parameters> |
		<Exclusive label restriction parameters>

    <Simple label restriction parameters> ::= <LabelSet> ...

    <Channel count restriction parameters> ::= <MaxNumChannels>

    <Label range restriction parameters> ::=
	<MaxLabelRange> (<LabelSet> ...)

    <Simple+channel restriction parameters> ::=
	 <MaxNumChannels> (<LabelSet> ...)

    <Exclusive label restriction parameters> ::= <LabelSet> ...

> So all parameters MUST be included for all RestrictionTypes?  I
> suspect you mean to say there alternatives based on RestrictionType.
> If correct, syntax is covered in

Addressed above.

> (<LabelSet>...) | <MaxNumChannels> | <MaxLabelRange> | (<LabelSet>... <MaxNumChannels>) | <LinkSet> 

Addressed above.

> s/MaxWaveWidth/MaxLabelRange

I think I sense some fatigue. (on my part too!)

OLD
   LABEL_RANGE:   Waveband device with a tunable center frequency and
   passband. This constraint is characterized by the MaxLabelRange
   parameter which indicates the maximum width of the waveband in terms
   of channels. Note that an additional wavelength set can be used to
   indicate the overall tuning range. Specific center frequency tuning
   information can be obtained from dynamic channel in use information.
   It is assumed that both center frequency and bandwidth (Q) tuning
   can be done without causing faults in existing signals.
NEW
   LABEL_RANGE:  Used to indicated a restriction on a range of labels
   that can be switched.  For example a waveband device with a tunable
   center frequency and passband. This constraint is characterized by
   the MaxLabelRange parameter which indicates the maximum range of the
   labels, e.g., which may represent a waveband in terms of channels.
   Note that an additional parameter can be used to
   indicate the overall tuning range. Specific center frequency tuning
   information can be obtained from dynamic channel in use information.
   It is assumed that both center frequency and bandwidth (Q) tuning
   can be done without causing faults in existing signals.

and
OLD
     MaxLabelRange is the maximum width of a tunable waveband switching
     device.
NEW (from general-constraint-encode)
   MaxLabelRange indicates the maximum range of the labels.

That's it, thanks,.
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Jan 2014 17:35:22 -0500

Young,

> New: The second 32 bit field (which is referred to by "Additional fields as necessary per action" in the below encoding) is a part of the base label used in many of the specific formats.

Well, this still isn't clear as the packet diagram doesn't show a 32 bit
field, it shows a variable length one.  How about:
OLD
  The second 32 bit field (which is referred to by "Additional fields
   as necessary per action" in the below encoding) is a part of the
   base label used in many of the specific formats.
 and
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Additional fields as necessary per action                |
     |                                                               |

NEW
   Action specific fields are defined below.
 and
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   (Action specific fields)                    |
     |                            ....                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Also, just noticed:
2.2.3. LABEL_RANGE1

What does the 1 indicate in the name?

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Jan 2014 17:35:26 -0500

Young,

It looks like you missed my in line comments. They still need to be
addressed.

Thanks,
Lou

---

From: Leeyoung <[email-masked]>
Date: Thu, 30 Jan 2014 00:20:06 +0000

Hi Lou,

Please see inline for my resolution to your comments. 

Attached is working version of draft-ietf-ccamp-rwa-info-20 and idnit results that indicate no issue found with the draft.

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2014 4:35 PM
To: Leeyoung; CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info

Young,

See below.

On 1/27/2014 6:46 PM, Leeyoung wrote:
> Changed:  <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> 
> [<InAvailableWavelengths>] [<OutAvailableWavelengths>])*
> 

As was the case below, an asterisk isn't valid RBNF, so shouldn't be in this line.

YOUNG>> This works for me. Thanks. 

So you now have:

Actually since the use of <ResourceBlockInfo> already indicates repetition in section 5, no  repetition is needed here, which yields

YOUNG>> This works well. In light of the next comment (with a consistent naming with encode draft, the following is agreed: 

<ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>] [<ProcessingCapabilities>] [<OutputConstraints>]

       0                   1                   2                   3

To me, I'd read this as

Which is correct?  Also note that you have ResourceSet in this document and "RB Set Field" in wson-encode-24. to align this document:
s/<ResourceSet>/<ResourceBlockSet>

YOUNG>> As discussed previously, <ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>] [<ProcessingCapabilities>] [<OutputConstraints>]. 

A few points here:

NEW

YOUNG>> Accepted. 

2) What is unclear is that when <PortLabelRestriction> what it must contain.  looking at 2.2 of wson-encode-24 I see

YOUNG>> Actually this is 2.2 of gen-encode-14. 

      0                   1                   2                   3

			
YOUNG>> OK. These are consistent with Gen-Encode-14. All accepted. 

> <RestrictionParameters> ::= (<LabelSet>...) | <MaxNumChannels> | 
> <MaxLabelRange> | (<LabelSet>... <MaxNumChannels>) | <LinkSet> (Note: 
> this is arranged to be consistent with 
> draft-ietf-ccamp-general-constraint-encode-13.txt in the naming and 
> order)
> 

Addressed above.

YOUNG>> OK.

> <GeneralPortRestrictions> ::= <RestrictionType> 
> <RestrictionParameters>  (RestictionType and one of the parameters 
> corresponding to the RestrictionType must be there)
> 
> <MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType> 
> <RestrictionParameters> (the same rational apples as above)
> 

Addressed above.

YOUNG>> OK.

OLD

YOUNG>> Accepted with a few grammar/style corrections: indicated -> indicate; For example -> For example,

and
OLD

YOUNG>> Accepted. 

That's it, thanks,.
Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 29 Jan 2014 19:49:22 -0500

Young,

Looks good to me.

Much thanks,
 Lou

On January 29, 2014 7:21:10 PM Leeyoung <[email-masked]> wrote:

> Attached is working version of draft-ietf-ccamp-rwa-info-20 and idnit 
> results that indicate no issue found with the draft.
>
> From: Lou Berger [mailto:[email-masked]] Sent: Tuesday, January 28, 2014 
> 4:35 PM
> > Here's my comments to your comments. Please see inline for detail. 
> Enclosed is a working draft that reflects all the changes per your comments.
> >> Here's my response to specific comments to draft-ietf-ccamp-rwa-info. >>
> >> Thanks.
> >> Young
> > YOUNG>> It was a mistake I think that took place while I was shifting 
> some references around. I will put [Switch] back to informative reference 
> section.
> >>
> >>    <DynamicNodeInfo> ::=  <NodeID> [<ResourcePoolState>] (section >> 7.2)
> >>
> >>    What's the intent here?
> >>
> > sorry, I didn't mean for you to incorporate the <ResourcePool> definition 
> into the document.  this was just for our discussion.  I don't think adding 
> a duplicate/incomplete definition here is the right thing.  So I'd drop it 
> (starting with Where.)
> > YOUNG>> OK. "Where..." is dropped. Also changes in Section 5.1: Original: 
> <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> 
> <InAvailableWavelengths> <OutAvailableWavelengths>)...
> > As <InAvailableWavelengths> <OutAvailableWavelengths> are only used in 
> the cases of shared input or output access to the particular block.
> >
> > >>
> >>
> >> YOUNG>> That means whatever within () can be repeated. >>
> Actually since the use of <ResourceBlockInfo> already indicates repetition 
> in section 5, no  repetition is needed here, which yields
>
> YOUNG>> This works well. In light of the next comment (with a consistent 
> naming with encode draft, the following is agreed:
> <ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>] 
> [<ProcessingCapabilities>] [<OutputConstraints>]
>
> > YOUNG>> <ResourceSet> is optional. I don't think section 4.1 of 
> wson-encode-23 treats this as mandatory. Wson-encode-23 document simply 
> provides encoding details irrespective of whether it is mandatory or 
> optional. Let me know if you disagree with this.
>
> Which is correct?  Also note that you have ResourceSet in this document and 
> "RB Set Field" in wson-encode-24. to align this document:
> YOUNG>> As discussed previously, <ResourceBlockInfo> ::= <ResourceBlockSet> 
> [<InputConstraints>] [<ProcessingCapabilities>] [<OutputConstraints>].
> > ...
> >>
> restriction parameters are always optional, but your text says that there 
> are requirements based on <RestrictionTypes>.  I think the BNF needs to be 
> aligned with the text and reflect the requirements.
> >>
> >> YOUNG>> Made all mandatory element. > > The new text says:
> you mean to say there alternatives based on RestrictionType.
> > YOUNG>> No. Indeed these parameters appear only if they match with 
> Restriction Types. So it should be as follows:
> <MaxLabelRange> | (<LabelSet>... <MaxNumChannels>) | <LinkSet> (Note: this 
> is arranged to be consistent with 
> draft-ietf-ccamp-general-constraint-encode-13.txt in the naming and order)
> >
> Addressed above.
>
> YOUNG>> OK.
>
> > <GeneralPortRestrictions> ::= <RestrictionType> <RestrictionParameters>  
> (RestictionType and one of the parameters corresponding to the 
> RestrictionType must be there)
> draft-ietf-ccamp-general-constraint-encode-13.txt, this section should be 
> updated to match.
> > YOUNG>> RestrictionParameters are now matching with 
> draft-ietf-ccamp-general-constraint-encode-13.txt.
> > s/PortSet/LinkSet

---

From: Leeyoung <[email-masked]>
Date: Thu, 30 Jan 2014 06:26:27 +0000

Hi Lou,

Please see inline for my comments. Here's working version draft-ietf-ccamp-general-constraint-encode-14 and the idnits results. 

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2014 4:35 PM
To: Leeyoung; CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-general-constraint-encode

Young,

> New: The second 32 bit field (which is referred to by "Additional fields as necessary per action" in the below encoding) is a part of the base label used in many of the specific formats.

Well, this still isn't clear as the packet diagram doesn't show a 32 bit field, it shows a variable length one.  How about:
OLD

NEW

YOUNG>> This is fine with me. Accepted. 

Also, just noticed:
2.2.3. LABEL_RANGE1

YOUNG>> Deleted "1". 

Much thanks,
Lou

> To: Leeyoung; CCAMP; 
> [email-masked]
> Subject: Re: [CCAMP] WG Last Call: WSON documents - 
> draft-ietf-ccamp-general-constraint-encode
> 
> Young, (all),
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Jan 2014 08:46:07 -0500

Young,

Looks good to me.

Much thanks,
Lou