Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.
Document: draft-ietf-homenet-dncp-05.txt
Reviewer: Thomas Heide Clausen
Review Date: June 16, 2015
IETF LC End Date: <Reviewed during (just after - apologies) WGLC>
Intended Status: Standards Track
Summary:
o I have significant concerns about this document and recommend
that the
Routing ADs discuss these issues further with the authors.
Comments:
o Is there any good reason why the authors have no listed
affiliation?
o It is somewhat contradictory that the abstract talks about
"...describes a protocol" and then later "...leaves some details
to be specified in profiles, which define actual implementable
DNCP
based protocols"
Does that not mean, then, that this document specifies an
algorithm,
a framework, and not a protocol?
o On that, I see "DNCP protocol" several places. Expanded, that
becomes
"Dynamic Network Configuration Protocol Protocol" ...
o In general, and despite actually knowing some of the core
algorithms
somewhat before this review, I found the document really tough
to
read, with convoluted sentences, inconsistent
requirements-language,
and a lack of introductory "here's the 1000ft view of the
protocol,
what it does, how it works, and under which conditions it
works".
o On that, I do not find the chosen structure of the document to
be
optimal for conveying an unambiguous protocol specification.
For one,
the same concepts are occasionally described slightly
differently.
For another, it is often hard to find the information needed to
parse a specific mandated processing (for example). I provide an
example of what I would suggest a better structure in the
below.
The goal is to provide first concepts and an overview, followed
by a
single, easy to identify place for "precise and unambiguous
definitions
of concepts", and then use those in the detailed expression of
the
protocol. Note that this is just an example, of course:
Section "Terminology:"
The Network State Hash is a hash value which
represents the
current state of the network, as known by a
node.
Section "Protocol Overview and Functioning"
When receiving a FOO TLV, the DNCP node
compares the received
Network State Hash with its own Network State
Hash. This
represents the consistency check rom RFC6206.
If same,
then...if not, then ....
Section "Protocol Information Bases"
For the purpose of this specification, the
Protocol
Information Bases are orgnaized as sets of
tuples ... any
implementation can chose whatever
representation it wants.
The Network State Information Base in a
DNCP node is a set
of tuples:
(x, y, z, w)
where x is ..., y is ..., z is ..., and
w is ...
Section "How to calculate the Network State Hash":
The network State Hash is calculated using the
information
from the Network State Information Base, as
follows:
1. First, the tuples in that
information base are sorted
in ascending order based on
....
2. Second, .... (concatenation)
3. Third, the hash function
from <profile> is used
4. Fourth, the first n bits of
the resulting hash value,
are retained, witn n being
from <profile>.
And then, in remaining sections simply reference the
Network
State Hash, which is now ubiquitously defined in a
single place.
I am taking this example, since when reading section
5.3 I found
myself chasing through the document, finding multiple
slightly
different definitions of "Network State Hash" -- but
beyond this
example, it generally does apply to the document as a
whole, and
certainly to all of the processing and generation
considerations in
section 5.
o As a general comment, the document would do well with a good
editorial
overhaul to bring consistency in language usage, consistency in
2119
terminology, coherence in defined terms and their definition,
document
structure, etc.
Major Issues:
o The introduction does not read well; it contains parts of
something that
could be considered as part of an applicability statement
(without it
being called out as such, and without forming a complete
applicability
statement), and does not actually introduce the protocol.
Reading just
the introduction and the abstract, it is very obscure if
this is a framework, a protocol, a building block, an
architecture, an
algorithm -- and, if either of those, what it is actually
accomplishing,
and why one would chose to use DNCP. It does, however,
transpire that
"whatever it is", it has two "modes" and that it requires
something
(presumably a routing protocol) to provide each "node" with a
topology
map.
Suggest that a proper introduction consisting of three parts
would be
beneficial: (i) what this document is, (ii) what doing DNCP
actually
gets you, and (iii) the operating conditions under which the
DNCP is applicable.
On the latter point, given that you state that DNCP requires
profiles
to provide "actual implementable DNCP based protocols", it
appears
important to understand what the limits for "what a profile can
give
you" are.
I am calling this out as a major issue, since I believe that it
is
not just editorial, but is a matter of scoping this document
correctly,
and in particular not falling into the trap of "claiming
applicability
where it's not".
o The document, in my understanding, defines an exchange format
with
limited ability to evolve, as simply "a steam of TLVs".
As long as there's never a need to evolve the TLV format
itself, and
as long as you do not run out of TLV types, that's not going to
be
a problem. The doc sets aside a 16bit TLV type space, that's
reasonable
enough, but I worry if eventually a DNCPv2 will need to evolve
the
format. One purely hypothetical example could be if a "sequence
number"
would be needed in each DNCP message to detect "link success
rates", or
something of that sort.
I do not have an actual example in mind -- and that's exactly
the point:
to be evolutive for the unknown future and (at the very least)
be able
to discriminate between "old" and "new".
A discussion could be had if a "version number" in each TLV
would do,
or if a concept of "protocol message with a version number" is
preferential. I do not believe, however, that "no version
number" is
viable.
o Noting that the "overhearing n reduncant transmissions" is a
key
retransmission suppression mechanism in Trickle, and that this
seems to assume broad/multicast, using unicast seems to
contradict
the statement of "consists of Trickle", at least in the way the
algorithm is defined in RFC6206. Note: it's fine to use an
algorithm
outside of its initial scope, but it should be with the caveat
of
"which of the characteristics still hold, and which do not"
o DNCP claims to be trickle based, yet supports unicast. It also
(apparently) is a request/reply protocol. It doesn't have
messages.
This document needs a good, and pedagogical, "protocol overview
and
functioning" section somewhere: one needs to get through the
end of
Section 5 before having even a vague idea of how DNCP works.
o The use of normative language is not as tight as could be
desired.
For example, a number of SHOULDs seem to really ought to be
"MAYs" since
not following the SHOULD won't break the algorithm. It would be
good
to walk through the document and take a careful look at these to
either MUST/MAY the SHOULDs, or to qualify the SHOULDs
remaining.
o I am going to go out on a limb here, and say that "the protocol
is
underspecified". That's a deliberately provocative statement,
but it
was honestly how I felt upon having completed the review.
The document does not help the reader get an intuitive
understanding
of the protocol functioning, but jumps right into minute
details --
requiring the reader to "build up her or his own model of how
DNCP
works". On having read the document a few times, I think that I
understand it -- but there's nothing permitting me to verify my
understanding, and thereby I'd not feel confident to be able to
provide an interoperable and independent implementation. I've
given
some comments in the "Comments" section as to what I think
would be
viable ways to improve this point.
o Section 5.3, penultimate paragraph:
"If keep-alives specified in Section 6.1 are NOT sent
by the peer
(either the DNCP profile does not specify the use of
keep-alives or
the particular peer chooses not to send keep-alives), some
other
means MUST be employed to ensure its presence. When the
peer is no
longer present, the Neighbor TLV and the local DNCP peer
state MUST
be removed."
"...some other means MUST be employed to ensure its presence."
--
followed by more MUST verage when a peer disappears...I am not
sure that
that's conductive to interoperable implementations.
Two implementatons may chose different "means" and then turn
off keep-
alives - and be non-interoperable.
For interoperability, we need:
o A mandatory to implement mechanism,
that always is
present, but can be complemented by
another "means", or
o A mandatory to implement mechanism,
which by way of a
specified negotiation mechanism can be
turned off between
two peers, to allow them to use another
"means".
If you argument is "...this will be specified in the profile",
then
you still should provide the two above in this document, with
the note
that "...and a profile may specify which from among these MUST
be
used in a given deployment"
o Section 8:
Interesting; I am not a security expert, but I am very curious
to
see the SEC-DIR review of this document. That said, section
8.3.1
contains normative verbage:
"A node MUST be trusted for participating in the DNCP
network if and
only if..."
Which I think needs a qualifier of the "If the certificate based
trust model is used, then a node must be trusted for ...."
Same goes for the subsequent SHOULD - it really reads as-if this
certificate based mechanism initially was intended as MTI, but
then
was backed away from subsequently without a complete cleanup of
the
text?
I do actually question the value of having a laundry-list of
trust
management methods, and for one of those (certs) a laundry-list
of all sorts of trust relationship establishment methods, in
this
document; this in no small part as the lists are explicitly
indicated
as "non-exhaustive" and that none are listed as "mandatory to
implement". Was any thought given to factoring this into a
seperate
document, and focusing in this document on one,
mandatory-to-implement,
security mechanism?
Minor Issues:
Introduction:
o 1st paragraph: "reachable nodes"; two things:
- I always have a problem with the term
"node"; it is often
used as a shorthand for "routers and
hosts, both". I was
given to understand that homenet
specifically did not want
to consider host changes?
- "Reachable" - does that mean something
as in "radio range",
does it mean "on the same link", does
it mean within a
specific (DNCP?) domain, or does it
mean simply "on the
Internet somewhere"?
o 2nd paragraph: "nodes that are currently accounted for":
- What does that mean?
- Also, the conclusion "Therefore unlike
Time-To-Live (TTL)
based solutions, it does not require
periodic re-publishing
of the data by the nodes" does actually
not follow from
the previous sentence in that paragraph.
- I actually do not think that the
introduction describes
what DNCP does, and so the comparison
to TTL-based
solutions is rather hard to get here.
- Continuing:
"On the other hand, it does
require the topology
to be visible to every node
that wants to be able to
identify unreachable nodes and
therefore remove old,
stale data."
This reads a lot more like an
applicability statement than
an introduction; the take-away when
reading this is:
"Each node must have something
that maintains
a topology map of the entire
network, such as
a (LS) routing protocol, for
DNCP to function"
Is that actually the intent here?
- "DNCP is most suitable for data that
changes only gradually"
How is the reader to interpret
"gradually"? Do you mean
"infrequently", or do you really mean
"gradualy"?
o Last paragraph:
"DNCP has relatively few requirements for the
underlying
transport; it requires some way of
transmitting either unicast
datagram or stream data to a peer"
This is a bit of a forward comment, but we now have
"nodes
that are accounted for" and "peers". I see neither
defined in
the terminology section.
"and, if used in multicast mode, a way of
sending multicast datagrams."
This is the first mention of two "modes" of this
protocol. This
loops back to an earlier comment, that the introduction
actually
does not introduce the protocol, but rather is an
incomplete
applicability statement.
"If security is desired and one of the
built-in security methods is to be used,
support for some
TLS-derived transport scheme - such as TLS
[RFC5246] on top of
TCP or DTLS [RFC6347] on top of UDP - is also
required."
I am not pretending to be a security expert, but "some
TLS-derived...such as ... on top of TCP or DTLS..." (i)
does not
sound like it could lead to interoperable
implementations, and (ii)
does not sound sufficiently tight as a MTI security
mechanism to
pass security reviews. Again, I am no security expert,
but perhaps
getting one looped in early would be advicable?
Terminology:
o Suggest adding "In this document ..." somewhere to this
text:
"For readability, any DNCP profile specific
parameters with a profile-specific fixed value
are
prefixed with DNCP_."
o DNCP network: I read this twice, and came away with two
different
understandings, perhaps you can clarify which it is:
o A set of nodes running DNCP, within the
same domain, and
for which a path betwen any two DNCP
nodes includes only
other DNCP nodes; i.e., a DNCP network
forms a connected
component with only other DNCP nodes.
o A set of nodes running DNCP. They may
be anywhere on the
Internet, they are part of the same
DNCP network as long
as they (through other means) have
learned of each others
addresses.
In the former, that'd be (for example) a deployment
within my
home -- in the latter, it could be a node in my home
and a node in
your home forming a DNCP network.
The text is not quite clear on this point.
o Link: a point of clarification here. In "DNCP network",
there was
talk about "unidirectional links" and "bidirectional
links"; in
"Link" the definition is somewhat vague "directly
connected" and
"can communicate". Could something like "without
decrementing TTL/
hop-count" be added, and could a statement on
bidirectionality
(IOW, that this is just an IP link) be added?
o "Interface" is overloading the term "port" (IP port)
which can be
confusing
o "Endpoint" - The definition "locally configured use of
DNCP" is not
clear -- are you really not talking about a DNCP
process?
I am not sure that it is clear how a DNCP process can
be "attached
to ... a specific remote unicast address, or to a
range of unicast
addresses that are allowed to contact"
I can see how a DNCP process can be configured to allow
connections
from a specific range of addresses, or can be
configured to connect
to a specific remote unicast address. Is that what you
mean instead?
o "Peer" - states that two peers "communicate directly".
For link,
the definition is "directly connected nodes can
communicate".
Would it then not be easier to say "a DNCP node on the
same link
as ..." ?
o "Node state"
"The hash function and the number of bits used
are defined
in the DNCP profile."
Suggest:
"The hash function and the length of the hash
value are defined
in the DNCP profile."
o "Network state hash" - same comment as for node state
(above)
Data model:
o "Latest update sequence number"
This may just be my personal taste, but does it hurt to
mandate
a specific way of doing the looping comparison? The
reason I
suggest this is, that it's one of those things where
creativity
in an implementation seems to simply be an invitation
for bugs,
and for little gain
o "Relative time delta"
Document talks about "a 32 bit number on the wire" --
does that
mean that wireless links are excluded?
o Related to terminology, there seems to be some
fuzzyness around
node and endpoint. For example, in data model one of
the things that
a DNCP node may have is:
"Unicast address: the DNCP node it should
connect with"
Does that mean *any* DNCP process (i.e., *any*
endpoint) at that
address, or a *specific* DNCP process at that address?
The same, but inverse, for "Range of addresses: the
DNCP nodes that
are allowed to connect" - is this "any DHCP process
(i.e., *any*
endpoint) on any of these addresses?
Following, the same section reads:
"For each remote (peer, endpoint) pair detected
on a local
endpoint, a DNCP node has..."
the following text indicating that there's some sort of
distinction
between which endpoint.
This whole thing needs some clarification.
Operation
o First a generic comment that Trickle itself has some
operating
conditions which scopes its applicability, and it would
behove
this document to, in its own applicability statement,
call out
those.
o On the same token, while the use of Trickle in an
unicast fashion
is possible, I wonder if (in general) unicast use is
advicable. I
appreciate that some links are point-to-point and so a
broadcast
across it becomes an unicast -- but, does that
necessitate being
called out?
IF the reason for this "because we can use TCP", then
be explicit
about this - but, also, that you're then not exactly
using Trickle
where and how it was intended. I wonder if you could be
explicit
as to what consequences this "alternate use of Trickle"
have? It
seems that the use of unicast is directly contradicting
the main
operating consideration of Trickle?
o 2nd paragraph states:
"the multicast transport does not have to be
particularly
secure"
What is the definition of "not have to be particularly
secure"?
Is cleartext OK? Authentication? Encryption?
Should I do something more?
5.1 Trickle-driven status updates
o First paragraph:
"Multicast MUST be employed on a
multicast-capable interface;
otherwise, unicast can be used as well"
If the interface is not multicast-capable, then unicast
can be
used as well as what? Certainly not multicast, since
the interface
is not multicast capable...?
o Continuing:
"If possible, most recent,"
What would make it "not possible"?
"recently changed, or best of all, all known
Node State TLVs"
OK, so assuming that for some reason (MTU limitation)
it is not
possible, does the above represent an order that I MUST
respect,
or is it "take a pick from among these, according to
your whim of
the day"?
"(Section 7.2.3) SHOULD be also included,"
SHOULD is a strong statement, especially when prefixed
by
"if possible". That, essentially, renders it a MAY.
"unless it is defined as undesirable for some
reason
by the DNCP profile
Now it DEFINITELY is a MAY since apparently a profile
can state
that these TLVs MUST NOT be included -- and, I assume,
since the
document permits it to do so, it is possible without
breaking the
algorithm.
o And, continuing again:
"If the
DNCP profile supports dense broadcast link
optimization
(Section 6.2), and if a node does not have the
highest node
identifier on a link, the endpoint may be in a
unicast mode in
which multicast traffic is only listened to.
In that mode,
multicast updates MUST NOT be sent."
Really hard to parse. Is that not equivalent to saying:
"If a DNCP endpoint is not configured to be in
multicast
mode, then it MUST NOT send multicast updates"
?
If it is, then say that -- if it is not, then a rewrite
is needed,
as that's what I manage to extract from the text.
5.2. Processing of Received TLVs
o First paragraph reads:
"The DNCP profile may specify criteria based on
which particular
TLVs are ignored."
Criteria for what? Do you perhaps mean:
"The DNCP profile may specify which TLVs to
process, and
which to ignore"?
Auxiliary question, then, and related to my penultimate
comment
to 5.1, are there any constraints on that, any risks
from ignoring
(or not) specific TLVs to the operation of the network?
o I am also confused by the 3rd sentence in the first
paragraph:
"Any ’reply’ mentioned in the steps below
denotes sending of
the specified TLV(s) via unicast to the
originator of the TLV
being processed."
This confusion is likely due to the lack of a
"protocol overview
and functioning" description [either as its own
section, or as part
of the introduction].
I know how trickle works. Trickle is a distributed
consistency
algorithm. When an inconsistency is detected, then an
action is
triggered that rectifies that inconsistency. DNCP
claims to be trickle based, but apparently also a sort of request/reply
mechanism. Combined with trickle-over-unicast-links, I
am not sure
what the protocol logic actually is. Reading through
to the end of
Section 5, I think that I understand the idea, but I
am not sure.
And the old "when in doubt, look at the state
machines" didn't help
either, there aren't any.
The point to this comment is, that the document
immediately jumps
into the details -- but forgets to give the "10000ft
view" of the
protocol functioning.
o First paragraph states two SHOULD. Would those not be
MUST? What
breaks if not respecting those criteria?
o 2nd paragraph, a "valid address", that definition is
rather unclear.
I understand that that's something specified in "the
profile", but
what is the relationship to the different addresses
discussed in
the data model section?
It is not clear what the parenthesis to this paragraph
means,
but that is probably again a case of the "use case" and
"protocol
overview" not being documented - the document so far
has nowhere
described interaction with outside processes.
o First bullet, but generally through these, and other,
bullets:
I had a really hard time deciphering this. First:
"The receiver MUST reply
with a Network State TLV (Section 7.2.2) and a Node
State TLV
(Section 7.2.3) for each node data used to calculate
the
network state hash"
Alright, off to find "network state hash".
The terminology tells me that it is:
"a hash value which represents the current state of
the network. The hash function and the number
of
bits used are defined in the DNCP profile.
Whenever a node is added, removed or updates its
published node data this hash value changes as
well. It is calculated over each reachable nodes'
update number concatenated with the hash value of
its node data. For calculation these tuples are
sorted in ascending order of the respective node's
node identifier.
Searching further, I find Section 5.1, but that simply
states:
"The Trickle state for all endpoints is
considered inconsistent and reset if and only if
the locally
calculated network state hash changes."
Next occurence is in these bullets, and then just
before Section 6,
"During
the grace period, the nodes that were not marked
reachable
in the most recent graph traversal MUST NOT be
used for
calculation of the network state hash, be provided
to any
applications that need to use the whole TLV graph,
or be
provided to remote nodes."
Alright, now I know what I can't use for calculating it.
A few occurences later, in section 7.2.2, in what looks
like a
section laying out the packet -- sorry, TLV -- format,
I see for
"Network State TLV":
"This TLV contains the current locally
calculated network state
hash. It is calculated over each reachable
nodes' update number
concatenated with the hash value of its node
data in ascending
order of the respective node identifiers"
Phew. Now, it does seem a little at odds with the
terminology. The
terminology states something about tuples that are
ordered. While
those tuples are not defined (they should be), at least
what is
described is clear and possibly can be implemented.
What is in 7.2.2
is not ant cannot.
This is an instance of a general issue that I have with
this
document: that it doesn't take a step back, and
properly define
things in a proper order, but dives into (and repeats)
details.
o Also to section 5.2, for each of the cases that are
described, could
a conceptual description of "what this corresponds to"
be added? For
example:
Upon reciept of a Node State TLV:
If the node identifier matches the
local node identifier and
the TLV has a higher update sequence
number than its current
local value, or the same update sequence number and a
different hash, the node SHOULD re-publish its own node
data
with an update sequence number 1000 higher than the
received
one.
It's not clear why it is a "SHOULD re-publish" (not
MUST, nor what
happens if SHOULD is not followed). And it is not clear
why 1000 ...
[I just pick this example, but it applies to all
processing bullets]
o In the same cases, it is a lot more readable (IMO) to do nested
bullets:
o If FOO; and either of:
- BAR
- GNYF
- BLAB
Then do all of the following:
- ...
- ...
- ...
o Otherwise, if not-FOO, ...
That's a personal preference, though, so feel free to disregard
this
comment.
o Section 5.3 and elsewhere, suggest replacing:
"If it comes via..."
by:
"If received over ..."
o Last paragraph in 5.3:
Same comment as 3rd comment to 5.1 made above.
o Section 5.4, first sentence:
"DNCP validates the set of data within it ..."
Should that not be:
"A DNCP instance validates the data within its data
sets ..."
?
Also, "nodes that are currently accounted for; what's the
definition
of "accounted for"?
o Section 5.4, first paragraph
The statement:
"therefore,
unlike Time-To-Live (TTL) based solutions, it does not
require
periodic re-publishing of the data by the nodes. On the
other
hand, it does require the topology to be visible to every
node that
wants to be able to identify unreachable nodes and
therefore remove
old, stale data."
which also appeared in the introduction, is copied verbatimly.
Once
more, the statement is a claim which is not supported, and that
which
follows "therefore" is not a consequence of that which comes
before
"therefore".
o Section 5.4, first paragraph
"When a Neighbor TLV or a whole node is added or
removed, the
neighbor graph SHOULD be traversed, starting from the
local node.
The edges to be traversed are identified by looking for
Neighbor
TLVs on both nodes, that have the other node’s
identifier in the
neighbor node identifier, and local and neighbor
endpoint
identifiers swapped. Each node reached should be marked
currently
reachable."
First comment, why SHOULD and not MUST?
Second comment, and now you made me go look...."neighbor"
sounds like
"someone on the same link as me" so the "neighbor graph" is
really just
a set relating "this node" and "another node which is on the
same link
as this node".
Yet, looking in the terminology, I see "Neighbor graph" defined
as:
"the undirected graph of DNCP nodes produced by
retaining only bidirectional peer relationships
between nodes.
Which doesn't sound as much like a "neighbor graph" as it does a
"topology graph" for the whole network.
So, is the terminology wrong, or is the definition wrong?
o Section 5.4, 3rd paragraph
Is it actually important that the content of that graph be
"purged"?
That sounds like an implementation detail -- rather, it sounds
like
the elements of the graph should "not be used for calculations
and
MAY be removed". Or, is there a specific requirement that I am
missing?
o Section 6.1, I do not understand the parenthesis in this
sentence:
Trickle-driven status updates (Section 5.1) provide a
mechanism for
handling of new peer detection (if applicable) on an
endpoint
Under what conditions is that applicable, and under which is it
not?
o Section 6.2:
"An upper bound for the number of neighbors that are
allowed for a
(particular type of) link that an endpoint runs on
SHOULD be
provided by a DNCP profile, user configuration, or
some hardcoded
default in the implementation."
A couple of things to that:
1) Can you explain the parenthesis? What type of
link?
2) How does "an endpoint runs on" a link?
3) Why SHOULD?
4) Is this specification seriously suggesting
"some hardcoded
default in the implementation" as a SHOULD?
[I am tempted to upgrade this to a "Major issue" simply because
of 4) ]
Also to 6.2, this particular optimization, do you have any
quantification of its actual benefit? What should I look for to
determine if this "optimization" yields a benefit or not? What
are
you trying to optimize? Over what link types does this function?
I am dubious that it "optimizes" much, if anything, across an
Ethernet, for example ...
o Section 7
As indicated previously, having to search through the frame
format
diagrams for "how to calculate the value" isn't ideal.
o Section 7.2.3, I worry when I see something like this:
"The whole network should have roughly the same idea
about the time
since origination of any particular published state."
What is the definition of "roughly"?
Is the "should" intentionally in non-caps?
What're the consequences if not?
[Note that trickle almost mechanically makes information
propagate
with non-trivial jitter across a network, so how do you ensure
this?]
o Section 7.2.4, CUSTOM-DATA TLV.
Given the description:
"This TLV can be used to contain anything; the URI used
should be
under control of the author of that specification."
It seems that (i) the description is self-contradictory: it
cannot
contain *anything* but can contain an URI?
Secondly, how is this supposed to work, what does it mean [for
DNCP]
that "the URI is under control of the author"?
Thirdly, what does "that specification" refer to?
Fourthly, why lower-case should? Indeed, why is the "control"
of the
URI of any importance to DNCP?
o Section 9, the bullet:
"When receiving messages, what sort of messages are
dropped, as
specified in Section 5.2"
Seems at odds with Section 5.2, which discusses TLV processing.
Nits:
Requirement Language:
o Please reflect Errata 499 for RFC2119 in the boilerplate
o The RFC2119 boilerplate could conveniently be in the
terminology
section, given that it is terminology.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
