Subject: [manet] DLEP-03 review

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 3 Oct 2012 16:35:23 +0200

All,

I promised Stan a review of DLEP-03 last week, and finally got around to getting it out. Apologies for this delay, hope that it still is timely.

I shall add that I provided a review of a previous version of DLEP privately to Stan, and I want to commend him and his co-authors on having reflected many of my concerns when they updated to -03.

Note that I have reviewed only the non-appendix parts of the document; some comments may apply also to appendices and there may be more comments to add to the appendices than that which I say in the below.

I include the annotated PDF, as well as the annotation summary as text below.

Respectfully yours,

Thomas

Annotation summary:

--- Page 1 ---

Highlight (yellow), 3 oct. 2012 13:32:
Intended status: Standards Track

Note (yellow), 3 oct. 2012 13:32:
Now I am nitpicking: I believe that the proper term here is "Proposed Standard"

Strikeout (red), 3 oct. 2012 16:29, TClausen:
mobile or

Strikeout (red), 3 oct. 2012 16:29, TClausen:
other

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
necessary

Note (yellow), 3 oct. 2012 16:29, TClausen:
I am not sure I would say "necessary" - maybe "recommended" ?

--- Page 4 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
cable/DSL modems

Note (yellow), 3 oct. 2012 16:29, TClausen:
The abstract spoke only about wireless. Should abstract be extended, or should the cable/DSL examples from into be removed?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
(in the case of cable/DSL modems)

Note (yellow), 3 oct. 2012 16:29, TClausen:
The abstract spoke only about wireless. Should abstract be extended, or should the cable/DSL examples from into be removed?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
individual

Note (yellow), 3 oct. 2012 16:29, TClausen:
As this is in introduction, perhaps add something about why this is (different distances, physical obstacles etc)? I know that the subsequent example illustrates this, but the previous sentences provide "abstract reasons"?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
a 

Note (yellow), 3 oct. 2012 16:29, TClausen:
suggest:
"exclusively detected  by way of a"

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
e.g.,

--- Page 5 ---

Note (yellow), 3 oct. 2012 16:29, TClausen:
suggest adding:
"is a signaling protocol that"

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP protocol

Note (yellow), 3 oct. 2012 16:29, TClausen:
As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundant: expanded it becomes "Data Link Exchange Protocol Protocol".

Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...."

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP protoco

Note (yellow), 3 oct. 2012 16:29, TClausen:
As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundant: expanded it becomes "Data Link Exchange Protocol Protocol".

Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...."

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Note (yellow), 3 oct. 2012 16:29, TClausen:
You should make it such that figures do not split across two pages. In xml, add a <vspace blankLines="999"/> before this figure (but I think you use nroff - I forget how one does there?)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP session

Note (yellow), 3 oct. 2012 16:29, TClausen:
At this point, the notion of "session" isn't introduced yet, so this is confusing.

--- Page 6 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
changed

Note (yellow), 3 oct. 2012 16:29, TClausen:
Do you mean "changed characteristics", or do you mean "the set of interfaces, forming the link, has changed members"?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
MUST

Note (yellow), 3 oct. 2012 16:29, TClausen:
You have not yet defined RFC2119 requirements language. In general, I think that introductions are non-normative, and so use of 2119-language therein is not recommended. Suggest "are expected to" for MUST and "can" for MAY in the introduction?

And, of course, make sure that these normative requirements are called out in the normative parts of the specification.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
MAY

Note (yellow), 3 oct. 2012 16:29, TClausen:
You have not yet defined RFC2119 requirements language. In general, I think that introductions are non-normative, and so use of 2119-language therein is not recommended. Suggest "are expected to" for MUST and "can" for MAY in the introduction?

And, of course, make sure that these normative requirements are called out in the normative parts of the specification.

--- Page 7 ---

Note (yellow), 3 oct. 2012 16:29, TClausen:
There is an RFC2119 errata, that stipulates that also "NOT RECOMMENDED" be included in this paragraph.

See http://www.rfc-editor.org/errata_search.php?rfc=2119

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
MUST

Note (yellow), 3 oct. 2012 16:29, TClausen:
You have not yet defined RFC2119 requirements language. In general, I think that introductions are non-normative, and so use of 2119-language therein is not recommended. Suggest "are expected to" for MUST and "can" for MAY in the introduction?

And, of course, make sure that these normative requirements are called out in the normative parts of the specification.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
MUST

Note (yellow), 3 oct. 2012 16:29, TClausen:
You have not yet defined RFC2119 requirements language. In general, I think that introductions are non-normative, and so use of 2119-language therein is not recommended. Suggest "are expected to" for MUST and "can" for MAY in the introduction?

And, of course, make sure that these normative requirements are called out in the normative parts of the specification.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Requirements

Note (yellow), 3 oct. 2012 16:29, TClausen:
I would recommend that section 1.1 be promoted to a top-level section 2, and titled "Terminology".

I would, then, also recommend actually defining the terminology used (session, peer, ....) in that section.

DLEP introduces and uses a whole slew of terminology, and I know that it would have helped me greatly had there been a single central place for me to go look that up as I read the document. As it is, I had to search through to find (at times, partial) definitions of a given term.

I believe that completely defining in a central place, and then consistently using through the document, the terminology is a great help for the reader, and is a good way also to ensure that one is consistent and correct when writing the spec.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
When

Note (yellow), 3 oct. 2012 16:29, TClausen:
Suggest:

"To break this race condition when it occurs, ...."

So as to render crystal clear that DLEP does actually recover.

Should it not be stated how a router discovers that a race condition is happening?

Even moreso, is this really an "Assumption" (as the section heading states)? I would think that it is an integral part of the DLEP design?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP utilizes a session-oriented paradigm.

Note (yellow), 3 oct. 2012 16:29, TClausen:
This is not really an assumption either. I think that this section should be better titled "Design Principles" or something, as there's nothing much (two exceptions, see comment later) in the section that actually are assumptions as such.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
the discovery process

Note (yellow), 3 oct. 2012 16:29, TClausen:
which discovery process?
"The discovery process, specified in section XX" ?
Or, an external process in another spec?
Or, a non-specified process?

--- Page 8 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP assumes that participating modems, and their physical links, act  as a transparent bridge. Specifically, the assumption is that the  destination MAC address for data traffic in any frame emitted by the  router should be the MAC address of a device in the remote node. DLEP  also assumes that MAC addresses are unique within the context of the  router-modem session

Note (yellow), 3 oct. 2012 16:29, TClausen:
This paragraph is the one of the two which contain real assumption, and so one of the paragraphs that, from this section, would fit the section header "Assumptions"

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
This document refers to a remote node as a "Neighbor"

Note (yellow), 3 oct. 2012 16:29, TClausen:
And this is a terminology definition. Again, I strongly suggest making a proper "Terminology" section, centralizing such.

Also on this point. In MANET, we have a - by now - well established use of the word "neighbor", even a protocol that has the word "Neighbor" in its title specified as RFC6130. I wonder if it would not behove us to come up with a different term here, so as to avoid confusion? For example, I can easily imagine a system using both DLEP and NHDP, in which case "neighbor" may refer to distinctly different concepts.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
an  information base

Note (yellow), 3 oct. 2012 16:29, TClausen:
I like defining a protocol as something operating on information bases!

That said, I also think that defining the information bases in a separate section is a great help: it allows the implementer to consider what data structures and data storage is required for making the protocol work - and, allows specifying the protocol operations (message processing) as operations on these information bases.

I would suggest that a section be added to the specification, entitled "Information Bases", in which the different information sets, and their content, be specified. This should come before the actual discussion and description of protocol operations.

I would guess that it also would render describing (and understanding the description of) the protocol message processing an awful lot easier.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
effecting

Note (yellow), 3 oct. 2012 16:29, TClausen:
affecting?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP assumes

Note (yellow), 3 oct. 2012 16:29, TClausen:
This would be the second of the only two sections containing actual assumptions

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
rolls over at 65535 to 0

Note (yellow), 3 oct. 2012 16:29, TClausen:
Need to specify how to properly identify that, e.g., seq# 5 then may be considered bigger than seq# 65530 -- i.e., roll-over behavior -- if any sort of ordering is required.

If not, then I would suggest that this be prefixed by "DLEP uses sequence numbers only for correlating a response to a request, and not for freshness information, i.e., two sequence numbers for the same destination are never compared for anything other than equality".

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
It is assumed that DLEP running over other transport  mechanisms would be documented separately.

Note (yellow), 3 oct. 2012 16:29, TClausen:
This needs to be more explicit:
"DLEP running over other transport mechanisms MUST be documented separately, and such specifications MUST register or specify appropriate code points to use"

Note (yellow), 3 oct. 2012 16:29, TClausen:
Two comments here.

1)	Suggest terming it "Credit Windows" or something, so as to avoid confusions of the sort "I would like to credit XXX with having come up with the efficient algorithm used to make whipped cream".

2)	This (and following, and part of the previous) sections really read as what we typically see described in a "Protocol Overview and Functioning" section.

I would therefore suggest that a section 2 be "Terminology", section 3 be "Assumptions" (containing the two paragraphs pointed out in the above) and a new section 4 added titled "Protocol Overview and Functioning".

In section 4, the remainder of Section 2, plus this section "Credits", and the following "Metrics" and "Normal Session Flow" be included as subsections to this proposed section 4.

I would even suggest that "Mandatory Signals and Data Items" also be included in this proposed section 4, as "Signaling Overview" and "Information Base Overview". The latter would even, in part, accommodate my previous comment as to making "Information Bases" appear more clearly.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP

Note (yellow), 3 oct. 2012 16:29, TClausen:
On to the credit windowing. When I spoke with Stan Ratliff in Vancouver, I didn't fully understand what this was really useful for, and almost considered it as "useless". After talking with Stan, wherein he patiently explained its use in a few eloquent phrases, I got convinced that it probably was not just a good idea, it was actually required in certain important cases ;)

I would recommend adding those eloquent explanatory phrases to the beginning of this section, as motivation for why this functionality is included in DLEP.

--- Page 9 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
.g

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Note (yellow), 3 oct. 2012 16:29, TClausen:
I think that my comment here refers to Figure 1.

Figure 1 explains that DLEP runs between a router and its modem, i.e., "locally" (wrt. the rest of the network). 

The credit windowing, as described in this paragraph, seems to relate to the "remote node". This is a little in conflict with 2 paragraphs up from here, at least it is confusing.

My understanding (ignoring what Stan said in Vancouver, but just reading and thinking hard about this section) is that:

1) If a router, R1 communicates to its local modem (but not beyond that), no credit windows is used
2) If a router, R1, communicates to a remote router, R2, by way of its local modem (m1) and remote modem (m2), then credits can be used. In that case, R1 will know of the credits corresponding to m2

Remembering back to what Stan said in Vancouver, this is not entirely correct, so I think that this section needs both some clarification and perhaps an example with a figure and a reference to figure 1?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
in the introduction  section of this document

Note (yellow), 3 oct. 2012 16:29, TClausen:
Use a section number reference here.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
within the network)

Note (yellow), 3 oct. 2012 16:29, TClausen:
Technically, it is not within the _entire_ network, is it? It only concerns those, with which a node has a direct link?

Underline (red), 3 oct. 2012 16:29, TClausen:
Peer

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Peer

Note (yellow), 3 oct. 2012 16:29, TClausen:
This is undefined so far - we have a (somewhat) definition of "Neighbor", but not "peer". Really need a good terminology section.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
specific characteristics

Note (yellow), 3 oct. 2012 16:29, TClausen:
I understand that you do not want to provide any firm data, but are there any guidelines or examples that can be provided?

--- Page 10 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP protocol

Note (yellow), 3 oct. 2012 16:29, TClausen:
As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundant: expanded it becomes "Data Link Exchange Protocol Protocol".

Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...."

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
experimental implementation

Note (yellow), 3 oct. 2012 16:29, TClausen:
That is fine. But....
If more link types become prevalent, should there also not be a space for future standards-action code points?

I can only think of a silly example right now, but consider this:

In the near future, smoke-signal based links will become prevalent, in which case we would want DLEP to understand meteorological data, as well as data concerning the stock of firewood of a remote modem, to accurately describe the characteristics of a link. Thus, the SSWG (SmokeSignal WG) specifies a DLEP extension for carrying and processing such data.

What happens in that case, compatibility wise? Can an existing implementation of DLEP in a router thus handle forward compatibility, when faced with a SmokeSignal Modem? 

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
maximum flexibility  for extending the protocol as conditions warrant

Note (yellow), 3 oct. 2012 16:29, TClausen:
I would make a counter-argument here:

having experimental spaces increases the probability of non-interoperating systems, especially if future evolution of the protocol is envisioned to happen by way of the experimental space.

I would feel a LOT more comfortable with a smaller experimental space, and then guidelines as to how to proceed to standardizing code-points  for future evolutions.

I should note that I didn't use to think like that, but our friendly AD (ADrian) managed to convince me.

I would therefore suggest that, at the very least, a generous space of code points be allocated to "Standards Action", and that this paragraph states that this is to be undertaken as or when the need arrises.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Normal Session Flow

Note (yellow), 3 oct. 2012 16:29, TClausen:
I won't comment on this section in great details, but I will make one overall comment: when I read it, I found myself doodeling a state machine on a napkin, to keep track of what the protocol was doing, and when.

I would suggest that such a state-machine could be interesting/illustrative to include. I didn't draw it in ASCII-text, so I can't provide a drop-in drawing, but if the authors are interested, then I could forward my napkin to them on occasion?

Note (yellow), 3 oct. 2012 16:29, TClausen:
I would like to see some sort of "Signaling overview" before the description of a state machine, of the sort:

"A DLEP device can send, receive and process the following signals:

NEED_MORE_APPLEPIE: 
sent when a DLEP device is out of apple pie

NEED_MORE_SOUR_CREAM:
sent when a DLEP device has apple pie, but
needs sour cream to consume with it

"
Another thing is, that the document - and this section in particular - talks about signals and messages in a bit of an incoherent fashion. I would recommend using "Signal" as the logical interaction between the devices, "Message" when referring to the actual bits and bit-format sent between devices.

Finally, a session exists between a router and its local modem, right? The state related to a session describes the "neighbors" (or is it peers?) reachable by the router via that modem? If so, then this would do well by being explained, perhaps in a Terminology section as the definition of "DLEP Session"?

--- Page 11 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
partners

Note (yellow), 3 oct. 2012 16:29, TClausen:
Is a partner different from a peer? or from a neighbor? => Terminology section.

--- Page 13 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP protocol

Note (yellow), 3 oct. 2012 16:29, TClausen:
As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundant: expanded it becomes "Data Link Exchange Protocol Protocol".

Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...."

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
SHOULD parse, and silently drop

Note (yellow), 3 oct. 2012 16:29, TClausen:
Disagree with this.
The requirement would be for an implementation not supporting an optional signal to identify and drop without processing the signal.

In terms of a message (the encoding of a signal into a byte format sent across the wire), it would be required to parse only the header, not the full message (presumably, the recipient not supporting an optional message would actually not be able to parse the message).

Actually, this links in with the whole "unknown/experimental" discussion: it should be such that an implementation not understanding a signal can identify and skip that signal (be it due to not supporting an optional signal or not understanding an experimental signal)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Packet

Note (yellow), 3 oct. 2012 16:29, TClausen:
Now, I am confused.

Does DLEP use the term messages or packets?

In RFC5444 we enshrined the notion of a packet as an encapsulation of a set of messages. I am not saying that we should use this format, or terminology, but it seems to me that we should be consistent inside a specification.

I see that section 9 and 10 try to make a distinction, but it still is very unclear and confusing

As I understand it, DLEP defines, in this section, a PACKET, with the type of the PACKET defining the interpretation of the content (the TLVs contained). But DLEP does not define a separate entity "message", rather a "message" is used for describing a "packet" in some circumstances. I think that, reading 9 and 10,  "A message is a packet containing some pre-defined set of TLVs", but that is very nebulous. Also, if I understand it correctly, does lend itself to a less clear parsing logic also (so either I do not understand it correctly, and it should be explained so that I do ;) -- or, I do understand it correctly, and we should come up with a clearer way ).

It seems confusing to have/use both terms, pick one. My personal preference would, probably, be message, but I have no strong religion on the choice of word, as long as *one* us used ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
INSERT REFERENCE  HERE].

Note (yellow), 3 oct. 2012 16:29, TClausen:
Yes, please do ;)

Note (yellow), 3 oct. 2012 16:29, TClausen:
OK, generally.....

1) It needs to be said how the fields are encoded. For most, the term "xxx is an n-bit unsigned integer field, which ..." seems to  be what is needed (versions, lengths, ...)

2) Some enetities (RouterID?) do not have length nor references as to how they are made. Are they IP addresses? MAC addresses? Derived so as to be unique, but otherwise without semantics?

3) I do not know what a "n bit unsigned number" is, but I do know what a "n bit unsigned integer" is.  I also do not know what a "n bit unsigned value" is, and even less how to encode "add/drop" and other  textual things into an octet, unless told so.

Change "number" and "value" and the like to "integer", or I will produce an implementation trying to read a version number as a float ;) And for "add/drop", tell me how to represent it, or I will come up with creative bit-patterns....

Note (yellow), 3 oct. 2012 16:29, TClausen:
I sorta think that it would be good to structure this section somewhat. For example:

One section for "Mandatory TLVs"
One section for "Optional TLVs"

Or a structure with a 2nd level section for all TLVs related to a specific "state" in the DLEP state machine?

Or something?

Also, I am somewhat iffy on this section mixing the syntactical structure of the messages/TLVs, and their processing. I would find it a lot cleaner to separate the two - a lot easier to read/implement. The separation is - kinda - started (section 11 and forward defines how/when messages are sent), so I would recommend trimming some of that information from this section. Writing the same thing in more than one place just means that it is easier for the specification to contradict itself ;)

--- Page 14 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP protocol

Note (yellow), 3 oct. 2012 16:29, TClausen:
As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundant: expanded it becomes "Data Link Exchange Protocol Protocol".

Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...."

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
TBD      Identification          TBD      DLEP Version          TBD      Peer Type          TBD      IPv4 Address          TBD      IPv6 Address          TBD      Maximum Data Rate (MDR)          TBD      Current Data Rate (CDR)          TBD      Latency          TBD      Resources          TBD      Expected Forwarding Time (EFT)          TBD      Relative Link Quality (RLQ)          TBD      Status          TBD      Heartbeat Interval/Threshold          TBD      Neighbor down ACK timer          TBD      Link Characteristics ACK timer          TBD      Credit Window Status          TBD      Credit Grant          TBD      Credit Request

Note (yellow), 3 oct. 2012 16:29, TClausen:
For this, you really should set up (and reference) the IANA registry, with mnemonics, and then just use that. This table reads like a "mini IANA section, outside of the IANA section", which is bound to be confusing and a source of errors.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
An 8-bit length

Note (yellow), 3 oct. 2012 16:29, TClausen:
An 8-bit unsigned integer field, containing the length....

Note (yellow), 3 oct. 2012 16:29, TClausen:
Should probably add that the encoding and internal structure hereof is specified for each of the different TLV types, given in the following.

--- Page 15 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Router ID

Note (yellow), 3 oct. 2012 16:29, TClausen:
This applies throughout this section:

How big is that field, and how is it encoded?
RouterID, is that a Well Known Entity?

--- Page 16 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
.g.

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Length

Note (yellow), 3 oct. 2012 16:29, TClausen:
Encoded how?

Note (yellow), 3 oct. 2012 16:29, TClausen:
Encoded how?

Note (yellow), 3 oct. 2012 16:29, TClausen:
Encoded how?

--- Page 17 ---

Note (yellow), 3 oct. 2012 16:29, TClausen:
Encoded how?

--- Page 18 ---

Note (yellow), 3 oct. 2012 16:29, TClausen:
Encoded how?

--- Page 19 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
TLV Flags=0x10

Note (yellow), 3 oct. 2012 16:29, TClausen:
Wait, what?

1) This TLV doesn't match the other TLVs: length comes after type. Hence, needs different parser-logic where none is needed.

2) The TLV Flags semantics is not defined anywhere, what does it mean that it is set to 0x10 ?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
number

Note (yellow), 3 oct. 2012 16:29, TClausen:
integer

Note (yellow), 3 oct. 2012 16:29, TClausen:
integer

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
number

--- Page 20 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
number

Note (yellow), 3 oct. 2012 16:29, TClausen:
integer

--- Page 21 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Note (yellow), 3 oct. 2012 16:29, TClausen:
8 bit unsigned integer?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
value

Note (yellow), 3 oct. 2012 16:29, TClausen:
integer

--- Page 22 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
number

Note (yellow), 3 oct. 2012 16:29, TClausen:
encoded how?

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Specific

Note (yellow), 3 oct. 2012 16:29, TClausen:
Set up an IANA registry for this, provide default registrations, and reference that registry here.

--- Page 23 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Interval

Note (yellow), 3 oct. 2012 16:29, TClausen:
Encoded how?

Underline (red), 3 oct. 2012 16:29, TClausen:
Threshold

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Threshold

Note (yellow), 3 oct. 2012 16:29, TClausen:
Encoded how?

--- Page 24 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Interval

Note (yellow), 3 oct. 2012 16:29, TClausen:
Encoded how?

--- Page 25 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
number

Note (yellow), 3 oct. 2012 16:29, TClausen:
Integer

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
number

Note (yellow), 3 oct. 2012 16:29, TClausen:
integer

--- Page 26 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
number

Note (yellow), 3 oct. 2012 16:29, TClausen:
integer

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
Reserved

Note (yellow), 3 oct. 2012 16:29, TClausen:
This field is reserved for future use. For compliance with this version of the specification, it MUST be  set to 0 on transmission, and SHOULD be ignored on receipt.

--- Page 27 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
DLEP Protocol

Note (yellow), 3 oct. 2012 16:29, TClausen:
As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundant: expanded it becomes "Data Link Exchange Protocol Protocol".

Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...."

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
string

Note (yellow), 3 oct. 2012 16:29, TClausen:
Technically, I would not say "string" (that has a common interpretation as a String datatype), but rather a "sequence" or better a "set" of TLVs

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
messages (signals)

Note (yellow), 3 oct. 2012 16:29, TClausen:
See previous comment re. message-vs-signal

--- Page 28 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
association

Note (yellow), 3 oct. 2012 16:29, TClausen:
This is  the first use of "Association" - is that the same as "session"?

--- Page 30 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

--- Page 33 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
OPTIONAL, and MAY be present if an implementation  supports them

Note (yellow), 3 oct. 2012 16:29, TClausen:
I know I am a nit-picker, but doesn't OPTIONAL exactly mean that it "MAY be present if an implementation supports..."?

It strikes me as just redundant (this is not the only place where I see this, btw., just the one where I chose to point it out.)

--- Page 36 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
e.g.

Note (yellow), 3 oct. 2012 16:29, TClausen:
The RFC editor uses:

"...blah blah, e.g., blah blah"

and
"...blah blah, i.e., blah blah"

Recommend making their life easier (and reducing their processing time) by just doing this from the start ;)

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
IANA Considerations

Note (yellow), 3 oct. 2012 16:29, TClausen:
First, let me point to http://tools.ietf.org/html/rfc5226

Second, for the registries set up, there needs to be specifications of what the ranges are (how big are the registries), what default allocations are made, and what the allocation policies (see RFC5226) are for these registries, and for specific intervals/parts of these registries.

You mention earlier that there are some experimental ranges, and that is good. What are they? Are there ranges requiring standards action? Expert review? What are the considerations that the experts must be aware of? Or, is it that the registries are infinitely big, and IANA should just register whatever they are asked to register?

--- Page 37 ---

Highlight (yellow), 3 oct. 2012 16:29, TClausen:
27.2  Expert Review: Evaluation Guidelines  

No additional guidelines for expert review are anticipated.

Note (yellow), 3 oct. 2012 16:29, TClausen:
I do not understand this.

Additional guidelines -- additional to what? IIRC, there are no "default expert review guidelines" anywhere in the IETF

Note (yellow), 3 oct. 2012 16:29, TClausen:
I do not understand this.

Additional guidelines -- additional to what? IIRC, there are no "default expert review guidelines" anywhere in the IETF.

(report generated by GoodReader)

Sent from my iPad