Skip to main content

Early Review of draft-ietf-homenet-hncp-04

Request Review of draft-ietf-homenet-hncp
Requested revision No specific revision (document currently at 10)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-07-23
Requested 2015-05-20
Authors Markus Stenberg , Steven Barth , Pierre Pfister
I-D last updated 2015-07-23
Completed reviews Genart Last Call review of -09 by Francis Dupont (diff)
Secdir Telechat review of -09 by Yoav Nir (diff)
Opsdir Telechat review of -09 by Sheng Jiang (diff)
Rtgdir Early review of -04 by Thomas H. Clausen (diff)
Assignment Reviewer Thomas H. Clausen
State Completed
Request Early review on draft-ietf-homenet-hncp by Routing Area Directorate Assigned
Reviewed revision 04 (document currently at 10)
Result Not ready
Completed 2015-07-23
[Apologies for the after-WGLC review]

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

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-hncp-07.txt
Reviewer: Thomas Heide Clausen
Review Date: July 21, 2015
IETF LC End Date: <review just after WGLC>
Intended Status: Standards Track

        o       I have significant concerns about this document and recommend
                that the Routing ADs discuss these issues further with the


        o       This document is a profile for and specialization of
                draft-ietf-homenet-dncp, and
                has a normative dependency on that document. Note that I
                produced a RTG-DIR review of draft-ietf-homenet-dncp with
                several suggestions a short while ago, to which the authors
                recently responded with an updated document. I have not had a
                chance to review that update, and iterate with the authors,
                yet. I also note a RTG-DIR review by Les Ginsberg, as well as
                several points raised by Juliusz Chroboczek on the topic of
                draft-ietf-homenet-dncp, the resolution of which I believe may
                impact draft-ietf-homenet-hncp somewhat significantly.

                This is one reason for my summary (above) of "Significant
                concerns..." -- before this document can be processed,
                draft-ietf-homenet-dncp should be squared off. It is not,
                however, the only reason

        o       As a general comment, the document would do well with a good
                overhaul to bring consistency in language usage, consistency in
                2119 terminology, coherence in defined terms and their
                definition, document structure, etc.

        o       Related to this, I found that the lack of a terminology section
                unfortunate, and ended up -- for helping my own reading of the
                document --  making a napkin-terminology to refer to as I
                walked through the doc. (FWIW, I personally prefer the
                2119-paragraph to be part of a terminology section, although
                that is a minor issue / personal preference). The words I'd
                suggest including, and defining, would be:

                        o       Node -- is that a router, a host, or both?
                        Again, I was
                                        given to understand that HOMENET did
                                        not want to redefine host behavior, and
                                        so I believe that the right term would
                                        be router?

                        o       Privat Link - Common Link -- If you *insist* on
                        having these
                                        concepts, then they definitely need a
                                        clear-cut definition here ; I would
                                        prefer, though, to not have those

                        o       External Interface
                        o       Internal Interface
                        o       Border
                        o       Border router

                You "import" a lot of terminology from DNCP and from
                [I-D.ietf-homenet-prefix-assignment], and I found myself
                constantly hunting through to figure out which terminology was
                from where. Suggest adding a paragraph to the terminology
                section (assuming you make one) which recapitulates something

                        "Additionally, this document uses terminology from DNCP,
                         specificially the terms XXX, YYY, ZZZ are to be
                         interpreted as described therein.

                         This document also uses terminology from
                         [I-D.ietf-homenet-prefix-assignment], specifically the
                         terms WWW, UUU, QQQ are to be interpreted as described

                Reason being: when I came across a term (say "Shared Link"), I
                wanted to make sure that I understood what that was. So I went
                to the terminology section. Well, there was none. So I went to
                grep through this document. Didn't really find a definition. So
                I started looking through the references to see if there might
                be something that made sense. Fortunately, my guess of what I-D
                to check first was right, but it still was more work than it
                should have been.

Major Issues:

        o       I made this very same comment to draft-ietf-homenet-dncp, as I
        am going
                to make here.

                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 what HNCP is actually
                accomplishing, and why one would chose to use HNCP.

                It does, however, transpire that "whatever it is", it imposes a
                src-dst routing protocol -- although, that is actually at odds
                with the claim (from the Abstract) that the use of HNCP allows
                "...seamless use of a routing protocol."  ... given that,
                afaik, no standardized src-dst routing protocols currently

                As I recommended for DNCP (hey, at least I'm being somewhat
                consistent...) I suggest that a proper introduction consisting
                of three parts would be beneficial: (i) what this document is,
                (ii) what doing HNCP actually gets you, and (iii) the operating
                conditions under which HNCP is applicable.

                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       4. Common Links

                From the document:

                   "HNCP uses the concept of Common Links for some of its
                    A Common Link usually refers to a link layer broadcast
                    domain with certain properties and is used, e.g., to
                    determine where prefixes should be assigned or which
                    neighboring nodes participate in the election of a DHCP(v6)
                    server.  The Common Link is computed separately for each
                    local interface, and it always contains the local
                    interface.  Additionally, if the local interface is not in
                    ad-hoc mode, it also contains the set of interfaces that
                    are bidirectionally reachable from the given local
                    interface, i.e. every remote interface of a remote node
                    meeting all of the following requirements:"

                Several issues here:

                        0)      "refers to a link layer broadcast domain" --
                        sounds like a
                                "full broadcast link" or "something that looks
                                like an Ethernet"
                        1)      "some of its applications" -- what are those?
                        2)      "usually refers to a ..." -- so, that means
                        that there are
                                situations where you use it to refer to
                                something else, then? Please don't do that....
                        3)      "is computed seperately for each local
                        interface" -- wait, in
                                0) it was defined in terms of physical
                                properties, now it is something which is
                        4)      "which neighboring nodes participate in the
                        election of a
                                DHCP(v6) server" -- is that a hidden
                                requirement that slid in, that DHCP(v6) servers
                                are part of the architecture? SLAAC is out,
                                then? Is that a conscious architectural

                                Now, I actually read in section 5, bullet
                                number 2 that "if an interface can receive a
                                delegated prefix by running a DHCPv6 client on
                                the interface, it must be considered external".
                                So, at least, if a "common link" connects
                                "internal interfaces" then if DHCPv6 servers
                                are active on a common link, then this imposes
                                constraints on what these DHCPv6 servers are
                                allowed to serve ... This *really* merits being
                                called out, the relationship DNCP-DHCP is
                                murky, at best.

                        5)      "if the local interface is not in ad-hoc mode"
                        -- haaaaang on,
                                if we are talking about an 802.11/WiFi
                                interface, "ad hoc mode” does not result in
                                links that look like in 0) ....not at all,

                        6)      "if the local interface is not in ad-hoc mode"
                        -- I am not sure
                                that this is actually "the right term" nor that
                                it is universally understood. At least, I have
                                personally had a heck of a time conveying what
                                that meant when charaterizing a link —
                                especually within the IETF"

                        7)      Reading forward in the document, there's
                        something more on that
                                in section 5 on page 6 where the document talks
                                about an "ad hoc category", and where it
                                actually says something about "transitivity
                                properties" -- specifically that it is not
                                assumed, then a reference to section 4 is given
                                as-if there was any further discussion on this

                        8)      "set of interfaces that are bidirectionally
                        reachable from the
                                given  local interface" -- I take it that this
                                means that the below specifies a part of a
                                protocol (HELLO protocol), which only run over
                                "ad hoc interface types"?

                If "yes" to 8), then I would recommend that you define the
                interface types, and their behaviors, completely -- both what
                characteristics you expect from the interface (and "ad hoc
                mode" is not sufficient...), and what behaviors you exhibit
                across them. You have, in this text, half-way defined
                "broadcast link type" and half-way defined a "non-transitive
                non-reflexive link type"

                Also, I really do not understand the choice of "Common Link" as
                section header, and as a term. How is that definition different
                from "an IP link"? Are the protocol mechanisms that you provide
                for what you call "ad hoc mode" providing something which looks
                like an IP limk to "the rest of the protocol", etc.

                I am afraid that I do not understand what a common link is. Are
                you trying to define a link model?

        o       3. DNCP Profile
                The document reads:

                        "A node implementing HNCP
                 SHOULD generate and use a random node identifier.  If using a
                 random node identifier and there is a node identifier
                 collision, the node MUST immediately generate and use a new
                 random node
                     identifier which is not used by any other node."

                Awesome, but that raises two questions:
                        1)      How does a node detect identifier collision?
                        2)      How does a node generate an identifier which is
                        not used by any
                                other node?

                It would seem that if 2) is actually possible, then a colission
                should never ever happen. Also, if 1) and 2) are done "by this
                protocol", put in a forward reference to where the
                corresponding mechanisms exist. Or if done by DNCP or something
                else, stick in a reference.

                As it is, it reads a little like:
                        "...and then some magic happens, and then poppies and
                        pink unicorns"


                The document reads:

                        "o  HNCP nodes use the following Trickle parameters:

                        -       k SHOULD be 1, as the timer reset when data is
                        updated and further retransmissions should handle
                        packet loss."

                I am wondering what the justification for "k=1" is here?
                Actually, I can infer what it is: the topology in a homenet is
                constituted by full-broadcast Ethernet links, with the
                assumption that "if one station receives a transmission, all
                stations on the link received the transmission" -- if so, then
                this is actually part of the applicability statement for HNCP:
                "MUST only be used on Ethernet-like links and MUST NOT be used
                on non-transitive, non-reflexive, or on lossy, links".

                If this interpretation is correct, then you probably should
                explain yourself --  for once, I am mostly in agreement with
                the use of a SHOULD.

                One question, however: for a router with multiple interface, do
                you run the Trickle algorithm per interface? Would probably
                merit clarification. If it is already said in DNCP (I do not
                recall if it is, and couldn't immediately find it), perhaps a
                reminder and a pointer would be good?

        o       Section 4 & 5
                The document seems to define a set of interface types and link
                types, but without any clear relationship between them -- and,
                worse, without any discussion of what characterize each, what
                behaviors are exhibited over each, and what impacts on the
                system/network behavior and performance each has. Further, the
                definitions of the different interface/link types are
                incomplete, and seem tied to (without naming explicitly)
                specific L2's...hinted at, but not actually referenced.

        o       Section 5

                The document reads:
                   "HNCP router's interfaces are either internal, external or
                   of a
                    different category derived from the internal one."

                So, this text tells me that there are n different categories of
                interface, where n>=2 -- but does not tell me what defines those
                different interface categories, or what the actual value for n
                is. Nor does this tell me if I should expect different
                behaviors across these interfaces, or not.

                Could the document be more specific?

                The text goes on:
                        "It is suitable for both IPv4 and IPv6 (single or
                        dual-stack) and
                         determines whether an HNCP interface is internal,
                         external, or uses another fixed category."

                So what's "another fixed category"? Is that different from "a
                different category  derived from the internal one" discussed
                earlier? Again, what behaviors to expect, exhibit, across these?

                With that being said, I would really recommend that the
                document defines what a border is, in this context. How do I
                identify it, what characterizes a boarder (which perhaps falls
                off from "what characterizes an internal and external

                I assume that "internal interface" means "internal to the
                Internet" whereas "external" means "external to the internet,
                i.e., part of the homenet" -- right? Of course, I am yanking
                your chain here, but you must define precisely what these mean.
                External and Internal are relative terms...

                On that, reading through the algorithm that you give,
                eseentially you define as "external" anything on which a DHCPv4
                or DHCPv6-PD server answers, correct? Other than having a hard
                time reconciling that with issue 4 under "common links" in
                Major Issues, that does seem to assume an architectural choice
                which imposes constraints ("thou shalt not run a DHCP server
                inside a homenet whilst running HNCP") which, at least, needs
                to be called out in the applicability statement for HNCP, and
                probably even merits more global discussion and decision by the

                But wait, then below the algorithm I read this:

                        "In order to avoid conflicts between border discovery
                        and HNCP routers running DHCPv4...."

                ...and then, requirements that such routers must include a
                User-Class string. That actually means that the specified
                algorithm is incorrect -- underspecified: the algorithm must
                capture the "...unless an User-Class string of .... is
                included", where appropriate.

                Sure, with efforts of the "...I thought this over, and I am
                sure that the authors must have meant XXXX", it's probably
                possible to implement but I'd much prefer to have the document
                tell me what to implement, rather than have it tell me to guess.

                The last paragraph in section 5 is hugely important: that is
                where the normative behavior for each interface category is
                detailed - but, I think, only part of the normative behavior is
                actually specified therein. This is relative to what I
                mentioned earlier, that for an interface/link type/category, it
                would be helpful to have specified precisely (i) how to
                determine if a given interface/link falls within it,  (ii) what
                precise behaviors to expect over than interface/link.

        o       Section 6
                Related to my last comment above to section 5, section 6 brings
                out "border routers" -- which is not actually defined in the
                document. Some specific behavior is specified for a "border
                router" and that brings me to expecting to see:

                        o       A precise definition of when a router is, or is
                        not, a
                                border router (given a router, how do I
                                determine if I should configure it to exhibit
                                that "specific behavior"

                        o       A precise and complete definition of which
                        behaviors a
                                "border router", once identified, should expect
                                and exhibit.

                The current text does not do that. Again, I could perhaps try
                to guess, but for a document aiming for std.track, I really
                should not have to.

        o       Section 6.1
                        "Each HNCP router MAY obtain external connection
                        information from
                         one or more sources, e.g., DHCPv6-PD [RFC3633],
                         NETCONF [RFC6241] or static configuration.  This
                         section specifies how such information is encoded and

                What is "connection information"? Do you mean "prefixes,
                addresses, routing information, DNS resolvers" and such?  Or
                does it mean "bitrate, error rate, propagation delay"? Or
                something else? Again, I could probably guess, and might even
                get it right, but in a std.track document I really shouldn't
                have to.

                        "o  MAY contain at most one DHCPv6 Data TLV and at most
                        one DHCPv4 Data TLV encoding options associated with
                        the External Connection but MUST NOT contain more than
                        one of each otherwise the External Connection TLV MUST
                        be ignored.

                     o  MAY contain other TLVs for future use.  Such additional
                        MUST be ignored."

                Several comments to that specifically, and to the TLV
                description in general (please apply also to the other
                signals/TLVs as appropriate, the comments to this TLV
                description / bullet apply through section 6):

                        0)      You define a TLV "EXTERNAL-CONNECTION", within
                        which you have
                                other TLVs, correct? Would it not be clearer if
                                those "other TLVs" be called "sub-TLVs" and
                                that term used systematically, so as to
                                distinguish them from the top-level DNCP TLVs.

                                I note that you then set up "sub-sub TLVs" such
                                as "Prefix Domain". So that means that we'll

                                        o       An EXTERNAL-CONNECTION TLV,
                                                o       A DELEGATED-PREFIX TLV,
                                                        o       A PREFIX-DOMAIN


                                The first question that springs to mind is one
                                of IANA registries. Are you setting up, for
                                each TLV type, a new registry for
                                sub-TLV-types? Or, are all TLV types out of one
                                global space?

                                More importantly, if out of a global TLV type
                                space, what happens if, say, a "PREFIX-DOMAIN"
                                TLV is received outside of a "DELEGATED-PREFIX"
                                TLV? Is that valid? Should it be? What behavior
                                should I, as an implementer, exhibit if I
                                receive that?

                                This, really, is a question about what the
                                context for processing each (sub)TLV os, or
                                should be, which is not specified in the
                                document. It is also related to issue 2) below.

                        1)      I would suggest a phrasing such as:
                                "MAY contain at most one ... and at most one
                                DHCPv4 ... with
                                 the external connection."

                        2)      The second part of the first bullet:
                                        "MUST not contain more than one ...
                                        MUST be ignored"

                                That should, IMO, be a generic comment for all
                                (sub)-TLVs, and brought forward to section 6.0
                                or 6.1, for example some wordsmithing on:

                                        "Any received TLV, which does not
                                        satisfy the requirements
                                         specified in the below, MUST be
                                         silently discarded, and MUST be
                                         ignored for processing.

                                More to the point, these TLVs (and (sub-)TLVs)
                                are speicified as being in a specific order, or
                                at least in a specific hierarchy (TLV within
                                another TLV) on transmission. What are the
                                constraints on their processing? At what point
                                shall I discard information based on it being
                                received "out of place" (such as a
                                "DELEGATED-PREFIX" TLV not contained in an
                                "EXTERNAL-CONNECTIVITY" TLV)?

                        3)      This leads to a general question: are all the
                        constraints on
                                the sub-TLVs contained in this TLV completely

                                I would actually like to see a check-list of
                                "constraints" that I could implement checks
                                for, both when generating and processing
                                protocol messages.

                        4)      Generally, to the fields in the TLVs, I do not
                        see the encoding,
                                (unsigned/signed, endianness, ...) stipulated.
                                Rather important for interoperability, this
                                MUST be clarified.

                        5)      I am generally not a great fan of having some
                        constraints in the
                                picture (such as the length >= 9) and some in
                                the text (such as "MUST NOT have more than n
                                occurences of FOOBAR").

                        6)      "May contain other TLVs or future use" -- sure,
                        but then you go
                                on to say "these MUST be ignored". Strictly
                                speaking, that means that you can't "future
                                use" them either. How about:

                                        "May contain TLVs of other type, for
                                        future use. For the
                                         purporse of the processing specified
                                         in this document, such TLVs of unknown
                                         TLV type MUST be ignored".

                                Note the subtlty here: "unknown TLV types" --
                                what does that mean? We're actually back at the
                                IANA/hierarchical/sub-TLV discussion. Assuming
                                that you have just one, flat IANA registry,
                                such as you actually have. An
                                EXTERNAL-CONNECTIVITY TLV sure is a "known TLV
                                Type". If you get a DELEGATED-PREFIX TLV
                                containing an EXTERNAL-CONNECTIVITY TLV, is
                                that valid, or must that be ignored?

                                So, with the current set-up of IANA registries,
                                the "unknown TLV types" is not the right phrase.

                                My preference in this sort of situation is
                                actually to set up hierarchical IANA registries:

                                        o       DNCP sets up the top-level TLV
                                        type registry. o       HNCP specifies
                                        (from within that regitry) the
                                                EXTERNAL-CONNECTIVITY TLV type,
                                                        o       Sets up a new
                                                        registry for sub-TLV
                                                        types o       Allocates
                                                        the DELEGATED-PREFIX
                                                        from that new

                                        (and so on).

                                What it does is to set up a context in which
                                "unknown TLV type" (and such) means something
                                -- and also solves the rest of the processing
                                context comments above

                                Alternatively, sure, you could put something

                                        "May contain TLVs of other type, for
                                        future use. For the
                                         purporse of the processing specified
                                         in this document, TLVs of types other
                                         than FOO, BAR, FOOBAR, and GNYF type
                                         MUST be ignored".

                                IMO this is less flexible and leads to more

        o       Section 6.1.2

                The document reads:

                        "Valid Lifetime:   The time in seconds the delegated
                        prefix is
                         valid. The value is relative to the point in time the
                         Node-Data TLV was last published.  It MUST be updated
                         whenever the node republishes  its Node-Data TLV."

        I just can't parse that. Well, I can, but what I get doesn't make
        sense to me:

                "relative to the point in time the Node-Data TLV was last

            So,  I publish a NODE-DATA TLV. Must I now remember when I did
            that, say, at t0, and then next time I publish a NODE-DATA TLV
            include (t-t0) as Valid Lifetime? That does look like what the text
            says, but it also doesn't sound like a "Vaid Lifetime". Given the
            name of the field, Lifetime, I would expect it to mean "Upon
            receiving this TLV, please consider the information valid for this
            much time" -- but, that's not what the text says.

                Same comment applies to Preferred Lifetime

                Also, from this section:

                        "*  Zero or more Prefix Domain TLVs.  In absence of any
                        such TLV the prefix is assumed to be generated by an
                        HNCP-router and for internal use only."

                Could gain from being a little more specific: what is "internal
                use only" (internal to whom?) -- related to my previous comment
                about definition of External/Internal. Also "use" -- do you
                mean that "this prefix MUST NOT be leaked externally, i.e.,
                addresses from within this prefix MUST NOT be used as a source
                address for traffic outside the homenet? If so, does this mean
                that you allow a homenet router to grab any odd global prefix
                and treat as private? Or, is this a matter of simply reflecting
                the already existing "don't route 192.168/16" (and equiv.)

                Either way, that needs to be clarified.

        o       6.2.1

                        "All HNCP nodes running the prefix assignment algorithm
                        MUST use the
                    following parameters:"

                First, I think that an element of clarification would be good.
                These parameters, where are they from? Do they come from
                [I-D.ietf-homenet-prefix-assignment], are they in that
                specification given as "optional" (so that one might get the
                idea to not use them), or?

                Second, is it the parameters - or their values - that must be

                This goes a little bit deeper; I think that what you are doing
                here is, in part, to specify "which values to assign to the
                different parameters from [I-D.ietf-homenet-prefix-assignment]"
                -- although that document is not particularly clear on which
                parameters form the interface to HNCP and to other protocols.

                But, the question is, what does it mean to "MUST use the
                following parameters" here? I can see that using these
                terms/definitions in the description of HNCP makes sense, but
                that does not a "MUST use the following parameters" make.

                So, I simply do not understand what you intend with 6.2.1.

        o       Section 6.2.2, 6.3, etc....

                This links in with previous comments regarding the hierarchy and
                location of protocol elements. The TLVs defined herin, are they
                "top level TLVs" or are they sub-TLVs, to be carried within
                another TLV? And, what's the context of their processing.

                This point is particularly obscure since the protocol does not
                act symmetric nor consistent here:

                        o       it defines an "EXTERNAL-CONNECTION" TLV (which
                                is what other protocols would call a
                                "messagge") which carries  sub-TLVs that have
                                to do with describing "EXTERNAL CONNECTIONS".

                        o       But, for Prefix Assignments, it does, as far as
                        I can tell,
                                not define a "PREFIX-ASSIGNMENT" message
                                (apologies, TLV) which contains the related

                I would like to see this through through -- ideally,
                re-engineered to be homogenous and consistent, but (at the very
                strict minimum) called out and explained clearly.

        o       6.2.3.  Making New Assignments

                   "Whenever the Prefix Assignment Algorithm subroutine is run
                   on a
                        Common Link and whenever a new prefix may be assigned
                        (case 1 of the
                    subroutine), the decision of whether the assignment of a
                    new prefix is desired MUST follow these rules:         "

                Hold on there for a second:

                        1)      What is "the Prefix Assignment Algorithm
                        subroutine"? Throw a
                                citation into
                                [I-D.ietf-homenet-prefix-assignment] here, so
                                the random reader knows what you're talking
                                about -- and, a section reference, also.

                        2)      This is exacerbated by the fact that the
                        descripton pointing to
                                "case 1 of the subroutine".
                                I guess that that correspinds to "bullet number
                                1" on page 9 in
                                [I-D.ietf-homenet-prefix-assignment], but in a
                                proposed standard, guessing should not be

                        3)      <general rant>
                                That aside, subroutines are programming
                                constructs, not specification elements. Just
                                out of spite, I'll go implement HNCP using
                                GOTO's instead of "subroutines" </general rant>

                        4)      I notice that sometimes this is called the
                        "Distributed Prefix
                                Assignment Algorithm", at other times "prefix
                                assignment algorithm”, then "Prefix Assignment
                                Algorithm subroutine", etc.

                                        o       Are they all the same?
                                        o       If yes, then why are they
                                        written, and capitalized,
                                        o       If no, then what're the
                                        differences between them?

                Next, the document reads:

                        "If the Delegated Prefix TLV contains a DHCPv4 or
                        DHCPv6 Data TLV,
                         and the meaning of one of the DHCP options is not
                         understood by the HNCP router, the creation of a new
                         prefix is not desired. This rule applies to TLVs
                         inside Delegated Prefix TLVs but not to those inside
                         External Connection TLVs."

                What does "is not desired" mean?

                        "...a new prefix MUST NOT be created?"
                        "...a new prefix SHOULD NOT be created?"
                        "...a new prefix MAY be created, but is not necessary?"

                The document reads:

                        "If the remaining preferred lifetime of the prefix is 0
                        and there
                             is another delegated prefix of the same IP version
                             used for prefix assignment with a non-null
                             preferred lifetime, the creation of a new prefix
                             is not desired."

                Suggest replacing "non-null" by "non-zero" -- but, beyond that,
                what does "is not desired" mean?

                Same comment for the next paragraph:

                        "Otherwise, the creation of a new prefix is desired"

                Am I right in reading these three paragraphs as:

                                1)      If <condition1> then new prefix MUST
                                NOT be created 2)      if <condition2> then new
                                prefix MUST NOT be created 3)      Otherwise,
                                if <condition 3> then new prefix MUST be created

                That is how the text reads, which begs the question:

                        Is it possible for <condition1>, <condition2>, and
                        <condtion3> to all not be satisfied, and what happens
                        in that case?

                I *think* that this is a case of underspecification, or at
                least where it looks like there's a case of underspecification.

        o       6.2.4:
                        "MUST create an appropriate route ..."

                What's "an appropriate route"?
                Do you mean "install entry into the routing table", or do you
                mean to launch a routing process to discover, calculate, or
                otherwise obtain that route? Do you need the entire path, or
                just the "next hop towards ..."?

        o       6.2.6
                        "When an HNCP router receives a request for prefix
                        delegation ..."

                OK, how does a HNCP router receive such a request? Grepping
                through the document fpr "request" I see no protocol signals
                that correspond to this.

                Then, this:
                        "The assigned prefixes MUST NOT be given to clients"

                made me wonder what a "client" is. I see DHCPv6/v4 client used,
                occasionally, and in other places I see just "client" -- is this
                intentionally, and, if so, what is a "client"?

        o       6.3

                        "Nodes MAY, at any time, try to reserve a new address
                        from any
                     applied Assigned Prefix"

                What is an "applied Assigned Prefix". Given capitalization, it
                is an "Assigned Prefix" that is applied somewhere, I suppose,
                but where and to what?

                The document reads:

                        For any assigned prefix for which SLAAC cannot be used,
                        the first
                    quarter of the addresses are reserved for routers HNCP
                    based address assignments, whereas the last three quarters
                    are left to the DHCPv6 (resp.  DHCPv4) elected router
                    (Section 10 specifies the DHCP server election process). 
                    For instance, if the prefix is assigned and
                    applied to a Common Link, addresses included in
           are reserved for HNCP nodes and the remaining
                    addresses are reserved for the elected DHCPv4 server.

                Why "the first quarter"? It seems a rather arbitrary value? Is
                it known to be enough/too much/too little?

                        "HNCP routers assign themselves addresses using the
                        Node Address TLV"

                OK, they send that TLV to themselves? Or do they send
                it to someone else, or ...? Part of the answer to this question
                is embedded in the text below the picture in section 6.3, but
                not all -- and, I believe, this is potentially another problem
                of more global scope.

                Generally, for each message (or TLV) it's good to know how it
                is formatted, but it's fantastic to know also how it's
                generated and how it is processed. I fali to find that (through
                and through) in this document, and that makes it harder to

                Would it be possible to do something like this, (generally, for
                the TLV types defined?):

                        Section X. FOOBAR TLVs

                        Section X.1 Generation
                                A FOOBAR TLV is generated when a, b, c happens.

                                When generating a FOOBAR TLV, its content is
                                determined as follows....

                        Section X.2 Processing
                                On receiving a FOOBAR TLV, take the following
                                steps ...

                That would also be the place (in X.1) to state where
                to put information (for example, when a TLV must be inside
                another TLV) or constraints on processing (X.2) for example if
                a TLV is invalid unless if contained inside another TLV.

        o       9 Securing Third-Party Protocols

                I take issue with the below:

                        "Pre-shared keys (PSKs) are often required to secure
                        IGPs and other
                         protocols which lack support for asymmetric security."

                Pre-shared keys are chosen, in some scenarios and for whatever
                reasons, regardless of the capacity of the underlaying
                protocols -- even when the protocol(s) (IGP or otherwise) are
                fully capable of and completely supports assymetric security.
                Please address this by a less broad claim for when PSK are used.

                But, I wonder, reading this section as a whole: you generate,
                and distribute through HNCP, a PSK? So all it takes to get
                access to said key is to sit by and passively listen to traffic
                for a bit? That does strike me as a dangerous option to
                have...reading the security considerations section, there seems
                to be nothing securing HNCP against eavesdropping -- or, if
                there is, that's not called out.

                I note that the security considerations of DNCP start out by

                        "If specified in the DNCP profile, either DTLS
                        [RFC6347] or TLS
                    [RFC5246] may be used to authenticate and encrypt either
                    some (if specified optional in the profile), or all unicast

                And, section 3 of HNCP states:

                   o  HNCP unicast traffic SHOULD be secured using DTLS
                   [RFC6347] as
                      described in DNCP if exchanged over unsecured links.  UDP
                      on port HNCP-DTLS-PORT is used for this purpose.  A node
                      implementing HNCP security MUST support the DNCP
                      Pre-Shared Key method, SHOULD support the DNCP
                      Certificate Based Trust Consensus and MAY support the
                      PKI-based trust method.

                Note the "SHOULD" and the conditonals "unsecured links" (not
                sure what this would be, precisely). I do not know anything
                meaningful about DTLS, but I would imagine that sking the
                SEC-DIR folks about its use would make sense.

                All that said...sadly, in many conditions and scenarios "getting
                security to work is hard" and in a home scenario the choice (to
                minimize the amount of support calls, ...) it would not be hard
                to imagine either turning OFF or using
                lowest-common-denominator security.

                Say "nothing" over an Ethernet "because physical access
                required", and WEP for WiFi (yes, people still do that) and
                then declare links "not unsecured" and therfore consider it
                legitimate to not implement the SHOULD.

                Effectively, what I fear here is that if HNCP "proposes to
                share PSKs" then a (slightly naive) process might actually
                trust those PSKs to be useful for security -- which, in fact,
                they are not since they can be exposed by simple eavesdropping?

                I'd really like a bullet-proof guarantee that any shared PSKs
                can't have been (easily) eavesdropped on -- or, would ratehr
                that HNCP does not tempt the use of compromized PSKs.

        o Section 10
                What's the solution if the message format changes? For example,
                that the type field needs to grow/shrink?

                I've mentioned this in my DNCP review, but I strongly believe
                that it is required to have versioning also capture "the frame
                format", and not just the "payload".

Minor Issues:

        o       General comments:

                        o       I recommend using "non-zero" when referring to
                        numerical values,
                                and not "non-null"

        o       Abstract

                Questions: is it clear what "naming" referres to? Is it "name
                        Idem for "network borders", do you configure those, or
                        discover those?

                Routing-specific question here:
                        What does "seamless use of a routing protocol" mean?
                        That any IP routing protocol can be used unmodified? I
                        *think* that that's not the case, given that the
                        use-case that is often trotted for homenet includes a
                        multi-homed home - and the introduction says as much so
                        the abstract probably should reflect that.

                How about somehting like this for the abstract:

                        "This document describes the Home Networking Control
                        Protocol (HNCP), an extensible configuration protocol
                        and a set of requirements for home network devices.
                        HNCP is described as a profile of and extension to the
                        Distributed Node Consensus Protocol (DNCP).  HNCP
                        enables automated configuration of addresses, name
                        resolution, discovery of network borders, and the use
                        of any src-dest-routing capable routing protocol.

        o       Introduction
                        "HNCP synchronizes state across a small site in order
                        to allow..."

                What precisely is a "small site"? Can we qualify that in terms
                of, say, number of routers?

                        "The protocol enables use of border discovery"

                I am not sure that I understand what this means -- in which way
                is border discovery *enabled*? Or, do you mean "This protocol
                discovers borders"? Or something else?

                        "naming and other services across multiple links."

                So, the first paragraph teaches me that HNCP is applicable
                somewhere not too big -- but, of course,  I do not know what
                exactly that is -- , and it does "some stuff, and other
                services" -- but, of course,  I do not know what those are, or
                how they are characterized. That's a little imprecise for an

                Suggest being extremely precise. Something like:
                        HNCP "Synchronizes state" by way of [dncp], and
                        specifies and uses state for providing the following
                        network services:
                                o       FOO
                                o       BAR
                                o       FOOBAR

                        All specified in this document. Additionally, HNCP
                        enables other services, characterized by ______, for
                        example prefix assignment as defined by

                Which brings me to a question. The abstract, and introduction,
                state that HNCP "enables automated configuration of addresses"
                -- how is that different from
                [I-D.ietf-homenet-prefix-assignment]? Or, is the answer "it
                isn't, that I-D is required to do that", in which case what
                does it mean that HNCP "enables" it?

                [Of course, reading the document it becomes clear that HNCP
                does this by way of a normative reference to
                [I-D.ietf-homenet-prefix-assignment], but the abstract and
                introduction really are unfortunately phrased]

                Reading just the introduction, I'd like to be able to know what
                HNCP would bring me, exactly? Implementing and turning on HNCP
                would do what to my network?

        o       3. DNCP Profile

                        "HNCP is defined as a profile of DNCP..."

                Is it not more correctly to say that"

                        "HNCP is a profile for DNCP..."


                        "HNCP routers MUST assign a unique 32-bit endpoint
                        identifier to
                         each interface for which HNCP is enabled."

                Any additional requirements to that identifier? Reading into
                DNCP, that is actually not entirely clear there. I *think* that
                the endpoint identifier MUST be unique to the local node, but
                that there's no requirement beyond that -- correct? Could that
                be called out both in this document, and perhaps in DNCP more

                Following the above:

                        "The value zero is reserved for internal purposes."

                What internal purposes would that be? Reading through, hidden
                in the description of the frame format (6.2.2) I read:

                        "The endpoint identifier of the local interface
                     that belongs to the Common Link the prefix is assigned to,
                     or 0 if the Common Link is a Private Link (e.g., when the
                     prefix is assigned for downstream prefix delegation)."

                OK, so leaving that slightly odd phrasing (and the notion of
                "Common Link" and "Private Link" -- both of which we will come
                back to) for a later comment, can we not bring this up to
                section 3, thus:

                        "HNCP routers MUST assign a 32-bit endpoint identifier,
                        unique to
                         the local node, to each interface for which HNCP is
                         enabled. The value zero MUST NOT be used, except as
                         endpoint identifier for an interface towards a Private
                         Common Link"


                [but, I am no great fan of "Private Link" or "Common Link", see
                other comments]

                About this:
                        "Received datagrams with an IPv6 source or destination
                        address which
                         is not link-local scoped"

                How about:
                        "Received datagrams where either or both of the IPv6
                        source or
                         destination address  is not link-local scoped"


                As a general comment, this section contains an unordered set of
                bullets, where a grouping and some common discussion probably
                would make sense. For example, a few concern security directly
                (e.g., 3 & 5) but are not really DNCP parametrizations --
                whereas others are (e.g., 6, 7, 8). The bullet-set reads
                somewhat like "the kitchen sink". (Numbers indicate count from
                the first bullet in the block).

        o       5.  Border Discovery

                The document reads:
                        "A router MUST allow setting a category of either
                     internal or external for each interface which is suitable
                     for both internal and external connections.  In addition
                     the following specializations of the internal category are
                     defined to modify the local router behavior:"

                What defines if an interface is "suitable" for an external, or
                internal, or both, connections? What does "connections" mean in
                this context? What requirements are there for an interface to
                be "suitable" respectively "unsuitable"?

                As part of the discussion of the different categories, some are
                declared as SHOULD, others as OPTIONAL. I do not see any which
                are MUST. I see that the two SHOULD should be MUST


                        Hybrid category:  This declares an interface to be
                        internal while
                still running DHCPv4 and DHCPv6-PD clients on it.  It is assumed
            that the link is under control of a legacy, trustworthy non-HNCP
                router, still within the same network.  Detection of this
                category automatically in addition to manual configuration is
                out of scope of this document.  Support for this category is

                What makes a router "legacy"? What makes it "trustworthy"?

        o       In section 6.1.2 I see:

                        "Nested TLVs:  Other TLVs included in the Delegated
                        Prefix TLV and
                         starting at the next 32-bit boundary following the end
                         of the encoded prefix:"

                        "Prefix:   Significant bits of the prefix padded with
                        zeroes up to the next byte boundary."

                        Other than "because historically that's how we did
                        things, because, at the time, that was a good idea", is
                        there any good reason that you're insisting on
                        byte/32-bit alignments here? It's been a good while
                        since I've personally written code where 32 bit
                        alignment was a major concern -- but, when generating a
                        packet I sure could see it as a minor nuisance to do
                        the alignment. So, I actually see this as "a nuisance
                        introduced in packet generation, for no real gain in

                        (Note that this is in the MINOR category, though)

        o       6.2.3:

                        "In any case, a router MUST support a mechanism
                        suitable to
                         distribute addresses from the considered prefix if the
                         link is intended to be used by clients.  In this case
                         a router assigning an IPv4 prefix MUST support the
                         L-capability and a router assigning an IPv6 prefix
                         MUST support serving router advertisements.  In
                         addition if an assigned IPv6 prefix is not suitable
                         for Stateless Address Autoconfiguration the router
                         MUST also support the H-capability as defined in
                         Section 10.

                To your credit, you put a forward pointer to Section 10. With
                that being said, would it not be more logical to discuss that
                (which appears as "the overall message format of HNCP")
                somewhere earlier?


        o       Any reason why some TLV types are written in ALL-CAPS whereas
        others in

        o       I saw a few "e.g." and "i.e.", which I believe the style guide
                prescribes should be "i.e.," and "e.g.,". Yeah, the RFC Editor
                will catch this ultimately, but if you re-spin the document
                then might as well make their life just a bit easier ;)