textual matters Re: LC model draft draft-ietf-forces-model-07.txt

Some editorial comments on this I-D, mostly a question of not understanding or
of
finding it hard to understand.  The biggest comment relates to attribute and
capability which I think warrants more discussion and, IMHO, a re-issue.

Overall,  it is an impressive document.

I think it could be easier to read; often there seems to be a choice of
good English style, eg using a fresh word, rather than consistently using the
one term for the same concept.  Likewise, LFB Class is sometimes LFB class;
consistency brings clarity.  And wherever an XML <element> is referred tot, then
I think the <elementname> should be there alongside, or instead of, any other
words..

Figures; there are two figure 2, no figure 4 or 8 (but references thereto) and
the placement is odd; sometimes before a reference, more often some way after.
I think it best if a figure is just after the first paragraph to refer to it.

Running footing refers to previous authors

s.0 [RFC-2119] not in references

s2.3 'The FE Model document..." Is that this I-D?

s2.4 "A full specification ... " unclear what this means

s2.5"ForCES requirement draft  " this should be a formal [reference] to an RFC

s3.2 "These LFBs .. " is this LFB Classes?

s3.2  The use of P and M, P' and M', conveys the impression that the packet and
metadata is the same on each output, which it need not be; better to use outputs
P1 (P2, P3...) and metadataM1 (M2, M3...) or some such notation.

s3.2 "A namespace is used to associate a unique name or ID with each LFB ..."
better "name and ID"

s3.2 " There is value to vendors .. " prefer implementors

s3.2.2 "For LFB instances that receive packets from more than one other LFB
      instance (fan-in). "  errant full stop.  I think.

s3.2.3 "labeled with a symbolic name and/or ID." I think this needs nailing down
as to which is used if either; I am confused by an earlier response about this
namespace.

s3.2.4 " We believe  that the same metadata model can be used .. " seems too
weak for an Internet Standard; drop the belief.

s3.2.4.2 " Ensuring consistency of usage of tags is important, and outside the
scope of the model. "  Mmm copout? if it is important, it needs addressing
somewhere; where?.

s3.2.4.4  " The metadata that is produced by an LFB is specified by the LFB
      class definition on a per output port group basis."  What about ports?
Since ports and port groups have been clearly differentiated earlier, omitting
one, which appears in several places, might be taken as a statement of intent.

s3.2.4.6 "Using  the other technique, ..." better to name the technique
explicitly

s3.2.6 "as described in detail elsewhere" where? [reference] needed

s3.2.6 " nor  information related in complex fashions" suggest 'information with
complex relationships'

s3.2.7 "Inheritance (discussed next in Section 3.2.6) " should be 3.2.8

s3.2.8 "(the default is the base LFB class" best to give this class its proper
name

s3.2.8 I am unclear from this whether all classes except the base inherit from
somewhere or whether there are multiple bases to inherit from

s3.2.8 "Backward compatibility can be designed into the inheritance model " but
is it?  Nail it down

s3.3.1 " topological approach is the most intuitive " suggest 'more' not 'most'

s4 " Each of the library documents will conform to the schema " are other schema
allowed as well or is this the only one?

s4.1. Namespace; is this an XML namespace or an IANA namespace?

s4.5 " (ala C unions" French a la or American aka or ...?

s4.5.3 "(for details, see the protocol" need a [document reference]

s4.5.3 "The following example shows a table" if this is an array, then calling
it an array, not a table, would make it easier to follow

s4.5.3 woule be easier to follow if the section with the definition of
ipv4prefix came before ipv4prefix is used in an array.

s4.5.4 " (using the <typeDef> element" do not understand <typeDef> it does not
appear elsewhere

s4.7 "Attribute and capability elementIDs must be unique within the LFB class"
is this one namespace of elementIDs or two separate namespaces?

s4.7.1 "element MUST be the unique name (<name>) " Yes, I think this explicit
inclusion of <elementname> is a must thoughout the document; it is if the text
after this point came from a different author..

s4.7.6 " The <event> element has an eventID " what is the namespace for this
eventID?  unique within the LFB Class defining it?

s4.7.6.2 " <eventDeleted/> the target must be an array, ending with a
           subscript indication.  The event is generated when an entry in
           the array is destroyed.  This occurs even if the entry is
           destroyed"
if this is eventDeleted, then it should be deleted not destroyed.

s 5.3.4.1."This is the ID in some space meaningful to the CE for the neighbor.
      If this table remains, we probably should add an FEID from the same
      space as an attribute of the FE. " seems rather vague

s7 After s4, I understood attibutes and capabilities
<attributes> define LFB Operational Attributes
<capabilities> define LFB Capability Attributes, and are read only
Except that in s3, I find capabilities - which appear to be attributes and
capacities - which appear to be capabilities; and then s7 has many references of
the form "LFB class specifications define a generic set of capabilities" err
attributes?
I see two clear concepts which need two clear Textual Labels which are then used
consistently throughout the document; having attribute as one of them seems a
poor choice, given its technical meaning within XML:  This for me is the biggest
editing problem with the I-D, a source of much confusion, and justifies
re-issue, once two clear Textual Labels have been identified.

s8 "show how a data plain LFB might be" as in Great Plains?

s8.1.1 "These two values are used by the LFB too look up" /too./to/

Tom Petch

----- Original Message -----
From: "Patrick Droz" <[email protected]>
To: <[email protected]>
Sent: Friday, October 13, 2006 10:36 AM
Subject: LC model draft draft-ietf-forces-model-07.txt


> I would like to issue last call on the model draft. As this is
> a fairly large document the LC will last for 3 weeks and will
> therefore end just before the next IETF. It is draft:
> draft-ietf-forces-model-07.txt
> and can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-forces-model-07.txt
>
> A number of people have indicated that if the document is in
> LC they would thoroughly review the document. I hope people will
> stick to their promises.
>
> Regards,
> Patrick