[Fwd: Fwd: review comments on draft-ietf-forces-protocol-08]

Here are my comments on draft-ietf-forces-protocol-08.  There are a
lot; some are just typos and the like.

However, I don't think this draft is ready yet.  There are four basic
problems that I see.

First, some basic concepts, like a path and key, are never explicitly
explained.  Since these are integral to the protocol, it's hard to
follow without them.  The examples in Appendix D do help to clarify,
but don't explicitly explain the concept.

Second, the protocol description is lacking details and some
consistency.  This is particularly a problem with the OPER-TLV.  The
BNF section also requires more work.  It is incomplete, refers to TLVs
that don't exist or aren't used, and so on.

Third, the two-phase commit protocol used for the atomic transactions
isn't fully described.  In particular, there is no indication as to
when the FE can discard knowledge about a transaction that the FE has
successfully completed. 

Fourth, the draft could use some reorganization. Information is
duplicated or missing.  The usage of the messages is described after
the message details; messages are mentioned, with caveats, before they
have been introduced, etc.  I have more detailed comments inside.  In
general, I suspect the draft could be shortened to provide a clearer
protocol description (but that's not something I'd say is explicitly
required).

I have not read through the associated model draft and looked for
issues between the two drafts yet.  I would be happy to do that once
some of these concerns have been addressed.

Anyhow, here are the detailed comments.

1) In 2nd paragraph on intro,

"The protocol includes commands for transport of LFB configuration
information, association setup, status and event notifications, etc."

Please expand LFB - the term hasn't been introduced yet & isn't obvious.

2) In Section 3, first paragraph.

"This document follows the terminology defined by the ForCES
Requirements in [RFC3654] and by the ForCES framework in [RFC3746].
The definitions below are repeated below for clarity."

Could you add a line making it clear that there are new definitions
(such as LFB), in addition to those from the Requirements and
Framework?

Also, if the terminology is to be used as a reference, it might be
useful to alphabetize it.

3) In Section 4, Overview

If there is overlap between this and the RFC3746, which is
authoratative (just in case)?

4) In Section 4.1.3,

"The FEM and CEM components, although valuable in the setup and
configurations of both the PL and TML layers, are out of scope of the
ForCES protocol.  The best way to think of them are as
configurations/parameterizations for the PL and TML before they become
active (or even at runtime based on implementation)."

should be

... The best way to think of them is as ...

5) Also in Section 4.1.3

"An example of typical of things the FEM/CEM could configure would be
TML specific parameterizations such as:"

Do you mean

An example of typical things the FEM/CEM ...

6) In Section 4.1.3, first paragraph of page 16:

"On start up the FE is in the DOWN state unless it is explicitly
configured by the CE to transition to the UP state via an FE Object
admin action.  This must be done before configuring any other LFBs
that affect packet forwarding."

Do you mean:

"On start up the FE is in the DOWN state until it is explicitly configured..."
                                         ^^^^^

7) At end of Section 4.1.3, on p. 16,

The following sentences are repeated before and after the Note.

"For the FE to properly complete the transition to the DOWN state it
must stop packet forwarding and that this may affect multiple LFBs.
How this is achieved is outside the scope of this specification."

8) In Section 4.2.2.2, last sentence of first paragraph:

"This continues until a termination occurs because of loss of
connectivity or is initiated by either the CE or the FE."
               
could be fixed to:

"This continues until a termination occurs, either due to loss of
connectivity or due to the termination being initiated by either the
CE or the FE."

or something similar & grammatically clear.

9) In Section 4.2.2.3, the second paragraph:

"It should be noted that loss of connectivity between TMLs is not
necessarily indicative of loss of association between respective PL
layers unless the programmed FE Protocol Object time limit is
exceeded.  In other words if the TML repairs the transport loss before
then, the association would still be valid."

I don't find this very clear.  Does the following say what you mean?

"The loss of connectivity between TMLs does not indicate a loss of
association between respective PL layers.  If the TML cannot repair
the transport loss before the programmed FE Protocol Object time limit
associated with the FE is exceeded, then the association between the
respective PL layers will be lost."

It is pretty clear that the FE has only one FE Protocol Object time
limit to consider.  I assume that the CE should consider the
association lost if the time out that the CE programmed for that FE
has expired.  I think this should be clearly specified - otherwise one
side could think the association lost & the other not. 

10) In  Section 4.2.2.3, the last paragraph says

"For this version of the protocol (as defined in this document), the
FE, upon re-association, MUST discard any state it has as invalid and
retrieve new state.  This approach is motivated by a desire for
simplicity (as opposed to efficiency)."

So, if I understand this correctly, the FE would stay in the UP state
after the association loss.  When the FE gets a new association, does
the FE continue to forward packets while it is obtaining the new
state?  When does the FE need to discard any state it has?  This seems
like it may be causing a deliberate traffic loss, not merely doing a
trade-off between simplicity and efficiency.  I think this needs a bit
more clarification.

11) In Section 4.3.1.1.1

"If there is any failure for any of the operations then none of the
operations will be executed, i.e there is roll back for this mode of
operation."

There is a difference between not executing an operation & doing a
rollback.  A rollback implies that there was a change which was then
changed back to its previous state.  In such a case, the temporary
change could affect the traffic. 

Do you mean that all operations should first be verified and, if no
errors occur, then be executed?  Or do you mean that attempting the
set of operations and failing can cause side-effects?

Please clarify the expected behavior here.

12) Section 4.3.1.2.2

I did not find this section clear enough for implementing.  I have a
few questions:

   a) If multiple FEs are involved, does the first message to each FE
   have the SOT specified?  Which have the MOT specified?  If only one
   message is needed to be sent to a particular FE, does the message
   have SOT and EOT specified?

   b) Can the EOT message have additional configuration information in
   it?  Does it have to?  Is it possible for there to be an otherwise
   empty message?

   c) Does an FE execute the transaction when it gets the EOT message?

   d) When can an FE safely discard all info about a transaction for
   which it has responded success to the EOT message?

I think that just a bit of clarification, particularly relating to the
multiple FE case would help.  I expect some of these details are
clearer in [2PCREF], but they need to be completely defined & clear in
this spec.

13) In Section 4.3.1.2.3, first paragraph

"Any of the participating FEs, or the CE, or the associations between
them, may fail after the EOT response message has been sent by the FE
but before it has received all the responses, e.g. if the EOT response
never reaches the CE."

The "it" is without a clear antecedant - please replace with "CE", if
that's what you mean.

14) In Section 4.3.2 and 4.3.2.2, command windowing. command window, &
command pipeling all seem to be referring to the same thing.  Could
you pick one term and just use that?  I'd vote for command pipelining,
since the windowing one makes me wonder what the window size is, how
it's controlled, etc.

15) In section 5,bullet 5

"It is expected that availability of transport links is the TML's
responsibility.  However, on config basis, the PL layer may wish to
participate in link failover schemes and therefore the TML must
support this capability."

Could you clarify the "on cofig basis"? Do you mean "Based upon its
configuration"?  This paragraph is fairly unclear to me, but maybe
Section 9 will clarify.

16) In Section 6.1,

In the figure for the common header, the correlator field is twice as
tall.  I see that it is supposed to be 64 bits.  Generally, I'd expect
to see that as:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Destination ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Correlator[32:63]                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Correlator[0:31]                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Otherwise, it looks like a typo & isn't clear whether the position is
[0:31],[32:63] or [32:63],[0:31].  Granted, the latter is solved by
the netwok byte order clarification, but it is still better to be
explicit.

17) In Section 6.1, in description of Source ID & Dest ID

"Each of the source and Dest IDs are 32 bit IDs which are unique
NE-wide and which recognize the termination points of a ForCES PL
message."

Do you mean "identify" rather than "recognize"?  If not, I'm not sure
what you mean.

Also, can a multicast or broadcast identifier be used for the source
ID?  What would it mean?  Is there any text that forbids it?

18) In Section 6.1, with the definition of priority,

What are the ordering assumptions that can be made between PDUs with
different (or the same) priorities?  This is relevant for the TML
requirements as well.  Do different priorities imply the messages can
be reordered?  I assume so, but that is something to explicitly
specify.

19) in Section 6.2,

Can the Value of the TLV be empty (i.e. 0 bytes)?

20) In Section 7.1.1,

I find this whole section confusing.  First, the format is a bit
different from the regular-expression based forms I'm used to seeing;
it does seem to be following RFC 2234, which I haven't seen used as
much.

Second, the grammer listed is incomplete and, to me, unclear.  For
instance, REDIRECT-TLV, ASResult-TLV, and ASTreason-TLV aren't defined
anywhere in the grammer, although they are used.  Also, additional
fields NOT SHOWN in the grammer are referred to & expected in the
description. For instance,

"OPER-TLV := 1*PATH-DATA-TLV"

In the description, later on, it turns out that the OPER-TLV has the
type field as well.  Granted, the name is a TLV, so it could be
clarified that any *-TLV will have the type & length fields first &
unmentioned, but this a confusing way of doing it, particularly when
you are just talking about 2 extra fields to specify in the BNF.
Generally, I expect the BNF to be complete - and this is not.

I'm not sure what to recommend, but those are some of my concerns.

This section is nearly unintelligible given reading the spec up to
here, plus the framework, and requirements RFCs.  

First, the types of messages haven't been explained yet, so random
restrictions and details based upon the message types, when the basic
communication exchanges haven't been described really doesn't help.  

For instance, what does

"A KeyID is used in a KEYINFO TLV.  It indicates which key for the
current array is being used as the content key for array entry
selection."

mean when there's no context for the current array, content key, etc.

Similarly, what about:

"DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1
or more further PATH-DATA selection.  FULLDATA and SPARSEDATA are only
allowed on SET requests, or on responses which return content
information (GET-RESPONSE for example).  PATH-DATA may be included to
extend the path on any request."

What about trying to define what the types of messages are and what
they can contain based on message type?

If the content of a "config" message would be different from an
"association" message (as stated in the paragraph after Figure 13),
why doesn't the BNF describe this?

If "MAIN-TLV is one of several TLVs that could follow the Mainheader.
The appearance of these TLVs is message type specific.", what are the
other TLVs?  Why aren't they listed in the BNF?  

Please try and clarify the text thinking about someone who hasn't been
thinking about the protocol for years.

For instance,

"LFBCLASSID is a 32 bit unique identifier per LFB class defined at
class Definition time."

could, I think, be clearer as

"When an LFB class is defined, it is assigned a unique value as an identifier.
LFBCLASSID contains such an identifier."

Similarly,

"LFBInstance is a 32 bit unique instance identifier of an LFB class"

could be

"LFBInstance is the identifier of a particular instance of an LFB
class.  See the definition of 'LFB and LFB Instance' for more
details."

What does the following mean?

"OPER-TLV uses the Type field in the TLV to uniquely identify the type
of operation i.e one of {SET, GET, DEL,etc.} depending on the message
type."

Doesn't the type of the OPER-TLV indicate that it is an OPER-TLV?  How
can the type also indicate different operations?  Is this referring to
multiple TLVs?  I only see one assigned a value in Appendix A!

Can you describe the constraint in the below paragraph in the BNF?

"PATH-DATA-TLV identifies the exact element targeted and may have zero
or more paths associated with it.  The last PATH-DATA-TLV in the case
of nesting of paths via the DATA construct in the case of SET requests
and GET response is terminated by encoded data or response in the form
of either FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV."

If not, why?

The summary in this section isn't a summary.  I don't know what it is
doing here.

I could continue, but probably a dialogue is best.

21) In Section 7.1.1.1,

The concept of a path hasn't been introduced yet in the spec.  That
makes this whole section rather confusing.  Is this really a discusion
on the grammer?

I'd recommend removing the first paragraph of this section.  It looks
like the third paragraph (after In other words) describes it much more
clearly.

22) In Section 7.1.1.1.1

The second paragraph is 

"The Value ("V" of TLV) of FULLDATA TLV will contain the data being
transported.  This data will be as was described in the LFB
definition."

No LFB definition has been presented yet.  Can you pull the relevant
text here or a pointer & clean up the language?

Also, can you please define FULLDATA, SPARSEDATA, etc. more fully
before trying to discuss the exceptions and details.

For instance, saying

"OTOH, when PATH flags are 00, the PATH may contain an index pointing
to a row in table; in such a case, the FULLDATA's "V" will only
contain the content with the index in order to avoid ambiguity."

doesn't help when the PATH flags haven't been defined yet. Some of the
issues may just be reordering content in the spec, but it's hard to
tell.

23) Section 7.1.1.1.5,

This section is good, but I've a couple issues.  First, there isn't
any definition of WHY an LFB select TLV exists or WHAT or WHEN it
should be used.  More minorly, it would help clarify to have the Class
ID and LFBSelect types specified with their value here.  That would
help to show what fields are constants & what they are.   For instance,
instead of:

'The type of the TLV is "LFBselect"'
you could have

'The type of the LFB Select TLV is 0x1000.  It may be referred to by
the constant LFBSelect.'

24) Section 7.1.1.1.6,

There is only one OPER-TLV defined in the IANA considerations, but the
section claims many different OPER-TLVs,with the difference indicated
by type.   Where is the complete list given??

Rather than referring to this confusingly an an OPER-TLV, it would be
better to clarify that there exists a set of TLVs that define
operations and give that set a name that doesn't imply that it is,
itself, a TLV.

At end of the first paragraph,

"Definitions for individual Types of operation TLVs are in
corresponding message description sections followed."

Should that be "as follows"?  Also, aren't these operation types & NOT
message descriptions?  The messages would, I assume, be indicated by
the message type in the PL PDU and not in the 4 different versions of
OPER-TLV.

In the second paragaph, it specifies "SET and GET Responses use
SET-RESPONSE and GET-RESPONSE operation TLVs."  What do the SET and
GET Requests use?  Why is the one specified & not the other?

In the 4th paragraph, the first sentence
"For a SET response, each FULLDATA or or SPARSEDATA TLV in the..."
                                      ^^
has an extra or.

At end of 5th paragraph, 

"So if a FULLDATA for a SET of a structure attempts to write one field
which is read only, and attempts to set another field to an invalid
value, the FE can return whatever error it likes."

would be clearer with "... the FE can return any one of the applicable
errors (e.g. READ-ONLY-ERROR or INVALID-VALUE-ERROR in this case)."

This section would be much clearer with an example.

Suppose the CE wishes to set a particular value in an LFB (pick a real
one).  Then show the CE SET-REQUEST and SET-RESPONSE (with a failure)
and then with a success.  Then show the CE querying the same value in
the LFB with a GET-REQUEST and GET-RESPONSE.

Also, this section never defines what is the value of the 4 different
TLVs.  That is kind of essential, with a description about what those
values are and mean.

Is there a DELETE operation TLV as well? The last paragraph seems to
imply it ("If the CE wishes to delete then the DEL operation should be
used whether the path refers to an array element or an optional
structure element.").

What other types of operation TLVs are there?  On p.44, it looks like
there is at least a SET-CREATE and a SET-REPLACE as well.  On p.51,
the REPORT-TLV is defined.

25) In Section 7.1.1.1.8,

What does "FULLDATA TLV may be used at a particular path only if every
element at that path level is present." mean?  What and where are path
levels defined?  I do not know how to interpret this.

26) On p. 44, Figure 16,

It would be clearer if, at the least, you put ... where you left out
information.  I assume that the second LFBSelect actually has path
targets.  An example with actual values would help as well.

Similarly, filling out values for Figure 17 would make it clearer.
How many IDs make sense here?  What could the flags be or not be?
Etc.

27) In Section 7.2, 2nd paragraph

"Although these LFBs have the same form and interface as other LFBs,
they are special in many respects: they have fixed well-known LFB
Class and Instance IDs.  They are statically defined (no dynamic
instantiation allowed)..."

This is the first indication I've seen that the LFB Class IDs, at
least, aren't well-known.  How else would they be learned?  I can see
an FE reporting what LFBs it can support and the instance IDs of each
instance of each LFB, but not without well-known class IDs.

28) In Section 7.2.1, on page 49, in the description of the CE
failover policy,

"0(default) - The FE should continue running and do what it can even
without an associated CE.  This basically requires that the FE support
CE Graceful restart.  Note that if the CE still has not been restarted
or hasn't been associated back to the FE, after the CE TI has expired,
the FE will go operationally down."

Do you really mean the CE (i.e. the original CE) or an acceptable CE
(original or a backup)?

Also, the term "CE Timeout Interval" is a bit confusing.  What about
the "CE Failover Timeout Intervale", which I think is a bit more
descriptive?

29) On p. 51, the first paragraph

Could you rephrase

"The Src ID (FE ID) may be set to O in the header which means that the
FE would like the CE to assign an FE ID for the FE in the setup
response message."

to be 

"The FE may set the Src ID to 0 in the header to request that the FE..."

30) On p. 52, Figure 19,

What are the contents of the first LFBselect? They and a nearly empty
line are missing.

31)On p. 52, in section 7.4.2, the last sentence of the Message Header
description:

"...The Dst ID in the header will be set to some FE ID value assigned
by the CE if the FE had requested that in the setup message (by SrcID
= 0)."

Could you add/change to the below or something similar?

"... The Dst ID in the header will be set to the Src ID in the
corresponding association setup message, unless that Src ID was 0.  If
the corresponding Src ID was 0, then the CE will assign an FE ID value
and use that value for the Dst ID."

32) In Section 7.4.3, under Message Header,

There is a period missing after "The ACK flag MUST be ignored"

33) In Section 7.5.1 on p. 55, under Message Header:

"The ACK flag in the header can be set to any value defined in Section
6.1, to indicate whether or not a response from FE is expected by the
message ( the flag is set to 'NoACK' or 'AlwaysACK'), or to indicate
under which conditions a response is generated (the flag is set to
'SuccessACK' or 'FailureACK').  The default behavior for the ACK flag
is set to always expect a full response from FE.  This happens when
the ACK flag is not set to any defined value."

The ACK field is only 2 bits long, so how can it be set to an
undefined value?  The rest, after "The ACK flag in the header can be
set to any value defined in Section 6.1...", is just repetitive
without adding any new information or insight.

34) In Section 7.5.1 on p.55 upder Type, only SET and DEL operations
are allowed.  Does this mean that the SET-REPLACE and SET-CREATE
mentioned on p.44 don't exist?

35) On p. 56, 2nd paragraph,

"Note: For Event subscription, the events will be defined by the
individual LFBs."

How does this relate to config messages?  The existence of events is
all that has been mentioned so far.

36) On p. 31, there is no indication of what messages the EM, AT, TP
flags apply to, nor does it seem to be discussed in the individual
message descriptions.

37) Having seen the table on p.68, this is good.  Why not put it in
the section where the Operational TLV is defined & then refer to the
restrictions that apply to a particular operation TLV?  That way, it
is clearer how many different types of restrictions there are & when
the same one applies.

Of more concern, think about how painful it would be, with how you
describe it, to add a new type of TLV to the PATH-DATA-TLV in the
future.  One would have to go through and clarify/special-case for
each message.  If this is given once where the different operation
types are defined, it would be easy to find & update.

The talbe on p.67 would be better placed in the operation tlv section
as well.

38) In Section 7.6.2, 2nd paragraph

"A query response message is also composed of a common header and a
message body consists of one or more TLVs describing the query result."

the "consists" should be "consisting".

39) For all response messages, the correlator must be that of the
corresponding triggering message.  Why repeat that for each message?
It is clearly stated on p. 29.  This sort of thing just helps obscure
the message-specific info that is needed.

40) Similarly, once a TLV has been introduced, every usage of it
doesn't need a reference to the original definition.

41) In Section 7.7, 2nd paragraph,

"A config message is used by CE to subscribe/unsubscribe for an event
in FE.  To subscribe to an event is usually by specifying to the path
of such an event as described by FE-Model and defined by LFB library."

would be clearer & grammatically correct as:

"The CE can subscribe to an event via a Config message, where the
included path specifies the event, as defined by the LFB Library and
described by the FE-Model."

42) In Section 7.7, on p. 61, under Message Header,

What does it mean for the correlator to be ignored?  What should it be
set to?  How about just having "Whenever the correlator field is not
relevant, because no response message is expected, the correlator
field should be set to 0." and putting that once on p. 29 with the
definition of the correlator?

43) In Section 7.8, p. 63, Message Body description:

"Consists of (at least) one or more than one TLV that describes packet
redirection."

should be

"This consists of one or more TLVs that contain or describe the packet
being redirected."

44) Section 7.8 looks like it needs some work to update to what
actually is to be done.  For instance on p. 64 after figure 32,

"Where, Meta Data ID is an identifier for the meta data, which is
statically assigned by the LFB definition.  This actually implies a
Meta Data ID transcoding mechanism may be necessary if a metadata
traverses several LFBs while these LFBs define the metadata with
different Meta Data IDs."

What does this mean for someone implementing?  What is really being
suggested?  If the LFB definition provides the context for the Meta
Dara IDa, then why not include an LFB class ID in the Meta Data TLV?

(Incidentally, Figure 31 has an incorrect title.)

Where are the RedirectSink and RedirectSource LFBs defined?  I don't
see any reference to them in the model draft.

45) In Section 7.8, on p. 65, first paragraph,

It says "For a RedirectSource LFB, via the meta data, CE tells FE
which port in the LFB the redirected data should go out."

What if the CE doesn't know - i.e., it is depending on the FE to do a
hardware lookup and forward accordingly?

46) In Section 7.8, on p. 65, last paragraph in section,

"This field presents the whole packet that is to be redirected.  The
packet should be 32bits aligned."

It would be useful to specify that the packet should be in network
order.  I hope noone would get that wrong, but...  Also, for the 32
bits alignment, specifying padding with 0s at the end would be good.
Additionally, how does the receiver tell the actual length of the
packet (redirected data)?  The Length field includes the padding, I
assume, so how does the receiver know?  Is this based on the
assumption that the packet is IP or self-identifying?  Please specify
this clearly.

47) In Section 7.9, it specifies

"The ACK flag in the header MUST be set to either 'NoACK' or
'AlwaysACK' when the HB is sent."

What should a CE or FE do if it isn't?  Why not have a rule that
anything else is treated as 'AlwaysAck' or as 'NoACK'?

48) Why not move Section 8 earlier in the document, so that the reader
has context for what the messages are for and how they are used?
Also, clean up the text a bit so that the exact message types are
specified (i.e. AssociationSetupResponse rather than setup response
message).

49) On p. 72, the last sentence refers to "Section 8", when it is in
Section 8.  I think the ref needs to be corrected to Section 9.

50) In Section 9, p. 73, the last paragraph

It isn't clear at what stage the FE should start claiming "too many
associations".  For instance, what if the FE hasn't successfully
established an association with a secondary CE?  I'm just looking for
a bit more detail on the sequence event.

51) In Section 9, p. 74, 2nd paragraph,

If the CE can force a change of Primary CE, when does that take effect
for the FE? Should the FE consider that equivalent to a loss of
association or an explicit termination?  Should the FE not care that
it is associated with a non-primary CE (as would happen when the
primary CE fails as well) until the association is lost or terminated?

52) In Section 9, given that the Report All mode is not fully
described, why not just mention that other modes may be supported in
the future and leave it at that?  The more you constrain what the
Report All mode is in this spec, the less freedom the spec that
actually defines it will have to get around any issues.

53) In Section 10.1.2,

"When CE or FE generates initiates a message,..."
I assume should be
"When CE or FE initiates a message,..."

"This extra processing step is recommend even if the underlying TLM
layer security services."
I assume should be

"This extra processing step is recommend even if the underlying TLM
layer provides security services."

54) In Section 10.2.1,

"When TML security services are enabled.  ForCES TML layer performs
endpoint authentication."

The first . should be a ,

55) Appendix A

There is an Operation Type Name space defined, but the OPER-TLV has no
extra type field, beyond that in the TLV.  Therefore, presumably, the
different types of OPER-TLV must come from the TLV Type space.

56) Appendix A.4

While MAIN-TLV is mentioned in the BNF, I didn't see it actually used
in any protocol messages.  What is it for?  Should it be here?

The META-DATA-TLV is missing from the list.

The OPER-TLV doesn't actually exist, apparently, b/c only the
sub-types of it do & they aren't nested (as far as I could tell).

57) In Appendix A.7,

The range from 0x1000 - 0x7FFFFFFF is not mentioned as to how it is
allocated.

58) In Appendix A.9,

The name space is described as 32 bits long, but the management
guidelines only go through 0xFFFF.

59) In Appendix C, Example 3 on p. 96

It would be useful to mention at the top of the page that b is
variable length.  One could guess by looking at the string type, but
that is easy to miss.

Also, at least some of these examples would be good to have where the
FULLDATA-TLV, SPARSEDATA-TLV, etc. are defined.  It's hard to tell
what is intended otherwise.

60) Appendix D

These examples might be easier to understand if there were some real
context to them, instead of meaningless names.

First, what does KEY mean in the context of a table?  For table1, is
the type of KEY nhkey?  Similarly for table2, is the type of KEY akey?
What space is the ID for the KEY from?  I guess it is separate from
the other IDs in the table.  I assume that the KEY is related to
Section 4.5.3 in the Forces Model draft, but without a thorough
reading of that, I'm not sure exactly what is intended.

At the bottom of p. 97 & top of p. 98, it says

"All examples will show an attribute suffixed with "v" or "val" to
indicate the value of the referenced attribute. example for attribute
foo2, foo1v or foo1value will indicate the value of foo1.  In the case
where F_SEL** are missing (bits equal to 00) then the flags will not
show any selection."

Why not just use val(x) as in the previous section of examples?
Particularly where the attributes are arbitrary pairs of (letter
number), it would help with clarity.

Also "example for attribute foo2, foo1v or foo1value will indicate the
value of foo1" needs to be cleaned up.

Example 4 again refers to a SET-CREATE-TLV. Does this TLV even exist?!?
Example 5 uses the SET-REPLACE-TLV...  Does this TLV exist?

Otherwise, these examples help clarify a lot.  I would try to move
some into the main text & include them in the explanations.  

For instance, the concept of a PATH or a KEY is never explained
throughout the document, and it really needs to be.

On p. 107, at the end of example 14, there are 3 SET-RESPONSES, when I
would have expected only 2.  Can you explain why?

61) In Appendix D, p 107

a few typos of "opertion" instead of "operation"
Also, using SET-REPLACE-TLV and SET-CREATE-TLV again