Subject: [CCAMP] AD review of draft-ietf-ccamp-general-constraint-encode

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 3 Nov 2014 14:55:14 -0000

Hi,

This I-D has been in the pipe for a very long time. Thanks for
persisting with it: hopefully we can stumble through the last stages
and achieve publication.

I have done my usual AD review. The intention is to apply some polish 
and to catch any issues that would otherwise gum up IETF last call and
IESG review.

Set out below you will find a number of relatively minor editorial points
and questions. But there are quite a lot of them, so I think you need to
address them either by responding to my email with rebuttals and 
explanations, or by updating the draft. I'm happy to discuss all/any of
the points.

I'll mark the I-D as "revised I-D needed" until we resolve this
discussion.

Thanks for the work,
Adrian

===

You have a reference to [WSON-Frame] in the first paragraph, but no
citation in the references section. I think it is Informative.

---

In section 1.1

   Note
   that this matrix does not represent any particular internal blocking
   behavior but indicates which input ports and labels (e.g.,
   wavelengths) could possibly be connected to a particular output
   port.

Should this read...

   which input ports and labels (e.g.,
   wavelengths) could possibly be connected to a particular port and
   label pair.

Further, you have

   The connectivity matrix is a
   conceptual M by N matrix representing the potential switched or
   fixed connectivity, where M represents the number of input ports and
   N the number of output ports.

This seems to have smudged the difference between port and label. Do you
not actually have a conceptual M*m by N*n where M represents the number
of input ports each with m labels and N the number of output ports each
with n labels?

---

Section 2 uses [RWA-Info] in a normative way. Please move the referenced
document into the Normative References section.

---

Section 2.1

Presumably you are anticipating more "Connectivity" types. I found it a
little hard to dream of one, but hey, perhaps the future will surprise
me. But will there be another 254 connectivity types? Or should this be
a 4 bit, 2 bit, or 1 bit field?

---

In section 2.1 the concept of a Matrix ID is introduced. I think you
need to discuss this concept in the introduction to section 2. You
need to explain that the ID is unique only on the advertising node, and
you need to explain why a node would have more than one matrix. You
probably also need to note whether a {port, label} can be present in
more than one matrix. Lastly, if two matrices have {sr port, src label,
dst port, dst label} for the same ports and labels, and the values
differ there is presumably some assumption.

I believe all of this is generic and not protocol specific, but maybe
it will help me understand why you need 255 matrices on any one node.

---

Section 2.2

   When more than one of these fields are present the
   resulting restriction is the intersection of the restrictions
   expressed in each field.

Do you really mean "intersection" and not "union". It seems to me that
the intersection of the restrictions is less of a restriction.

---

Section 2.2 

For the explanation of RestrictionType you need to give a forward
pointer to Sections 2.2.1 through 2.2.5 so that the reader isn't
puzzled.

---

Section 2.2 needs to explain the "Additional Restriction Parameters per
RestrictionType" field.

---

Section 2.2.1

   In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or
   MatrixSpecificRestrictions) format is given by:

What are GeneralPortRestrictions and MatrixSpecificRestrictions?

---

2.2.1 and 2.2.4 need to point forward to 2.6 for the definition of label
set.

---

2.2.3 needs a forward pointer to 2.6.2 for the explanation of label
range. Indeed, the whole of this section is hard to interpret. I can't
read it and apply any meaning to the protocol object.

Furthermore:

   It is assumed that
   both center label and range tuning can be done without causing
   faults to existing signals.

Is a passive voice assumption.  Who is assuming this? What if she is
wrong? Who is responsible for making the assumption correct?

---

2.2.5

   In this case the accompanying port set indicate that a label may be
   used at most once among the ports in the link set field.

Not only would a forward pointer to 2.3 be useful, but you need some
clarity between "link set" and "port set".

---

2.3

Why is <ConnectivityMatrix> in angle brackets?

There are just two other uses of angle brackets in the document. Why?

---

2.3

Does the Action field need a registry to track values? 

I am surprised that you think there may be 255 potential settings.

---

Section 2.3

   All Local Interface IP Address are supplied in
   the context of the advertising node

Aren't IP addresses scoped a little more widely?

---

Section 2.3

Wondering why you want a length field rather than a count field.

---

Section 2.4

Priority needs some explanation or reference. Priority with respect to
what?

   At least one priority
   level MUST be advertised that, unless overridden by local policy,
   SHALL be at priority level 0.

I cannot parse this at all! 

---

Sections 2.3, 2.4, and 2.6 seems to have origins in section 2.2 and can
have the necessary forward pointers included.  But where does section
2.5 come from? Where does the "Shared Backup Labels Field" sit?

Assuming that question can be answered, the same issues apply as voiced
for section 2.4.

---

In 2.6 or its subsections you need to explain the Num Labels field.

The explanation of Length in 2.6 is a little lacking, as well...

   Length is the length in bytes of the entire field.

...which "field"? ... why do you need the label count and the length
field?

---

2.6.2

Curious effect if I set start label equal to end label but am required
to set num labels equal to 2.

---

2.6.3

Only support 4096 labels in a bitmap set? Really?

---

In the second example in A.2

"Length = 20 bytes" seems to be wrong
Why does every entry have "n  for lowest frequency"?

---

Section A.3

   This representation uses only 30 32-bit words.

But I count only 29 32-bit words.

---

In A.5 the two priority fields seem to be wrong. I expected 

|1 0 0 0 0 0 0 0|

and

|1 1 1 1 1 1 1 1|

---

[G.694.1] seems to appear as a normative and informative reference.
Furthermore, it isn't actually referenced, but then neither is
[G.694.2].