Subject: [homenet] WG Actions

From: Ray Bellis <[email-masked]>
Date: Thu, 5 Mar 2015 14:25:29 +0000

Mark and I have just started a two-week WGLC for draft-ietf-homenet-prefix-assignment:

> Subject: IETF WG state changed for draft-ietf-homenet-prefix-assignment
> Date: 5 March 2015 12:33:18 GMT
> 
> The IETF WG state of draft-ietf-homenet-prefix-assignment has been
> changed to "In WG Last Call" from "WG Document" by Ray Bellis:
> 
> http://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/

As Mark previously suggested we've now also adopted draft-ietf-homenet-hybrid-proxy-zeroconf-00 as a WG item.

We had hoped to start WGLC for the two Front-end Naming Delegation drafts but it seems that the issue of how to transfer zones when the IP address of the hidden master has changed still requires further work and review.

Please provide further reviews for the recently updated draft-ietf-homenet-dncp and draft-ietf-homenet-hncp-04.  We believe these are very close to ready for WGLC.

Finally, as you'll have seen, Margaret just posted draft-mrw-homenet-rtg-comparison-02.  We'd like to thank her and her co-authors for the extraordinary effort they've put into this.  We would strongly encourage your feedback.

thanks,

Ray and Mark.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Mar 2015 14:11:02 -0400

Here are my last call comments on draft-ietf-homenet-prefix-assignment:

"implementing reliable broadcast" seems like an imprecise specification of "Flooding Mechanism". Exactly what characteristics are desired for the Flooding Mechanism: reliable delivery of the state of "published Assigned Prefixes" within some time limit?

Might seem like a nit ... but what is a "node"?  Always a router?  Can it be a host?  Is it some abstract function that can appear in either a host or a router?

Editorial: in the definition of Private Link, "requesting router" would be a better term than "client" (see RFC 3633).

Are Shared Links identified in some way in the mechanism?  If so, how?  I see the phrase "there never is more than one Assigned Prefix per Delegated Prefix and Link pair", but I don't see how a Link is identified.  Similarly, "The Assigned Prefix is advertised through the Flooding Mechanism as assigned to its associated Link"  Or maybe I'm missing something and the identification isn't necessary?

- Ralph

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 18 Mar 2015 09:04:03 +0100

Hello Ralph, 

Thanks for your comments.

> "implementing reliable broadcast" seems like an imprecise specification of "Flooding Mechanism". Exactly what characteristics are desired for the Flooding Mechanism: reliable delivery of the state…

I also believe ‘Reliable Broadcast’ does not help understanding what the flooding mechanism is.
What about this definition ?
OLD: A mechanism implementing reliable broadcast and used to advertise published Assigned Prefixes.
NEW: A Mechanism allowing participating nodes to share information with all other participating nodes. 

> Might seem like a nit ... but what is a "node"?  Always a router?  Can it be a host?  Is it some abstract function that can appear in either a host or a router?

Any device implementing the algorithm. May be a host, a router, a human... I mean, the algorithm is not specific to IP, so it may be anything.

> Editorial: in the definition of Private Link, "requesting router" would be a better term than "client" (see RFC 3633).

Good point. Thanks.

> Are Shared Links identified in some way in the mechanism?  If so, how?  I see the phrase "there never is more than one Assigned Prefix per Delegated Prefix and Link pair", but I don't see how a Lin…

It is necessary, but out of the scope of the document. Because it strongly relies on the context, e.g., whether links are numbered or not, or the type of messaging.
For instance, in HNCP, we use a 32bits integer to identify node's interfaces. HNCP then uses neighboring information to know if a prefix is assigned on a directly connected interface, and if so on which one.

Thanks,

- Pierre

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Mar 2015 08:10:51 -0400

Responses in line...

One key question I forgot to ask: text such as "Assigned prefixes are not included in and do not include other assigned prefixes" implies to me that the assignment algorithm accommodates assigned prefixes other than /64.  If I have that right, I think it would be useful to state that property explicitly.

Another new question about this text in section 4.1:

   Best Assignment:   For a given Delegated Prefix and Link, the Best
      Assignment is (if any) the Advertised Prefix:

      *  Including or included in the Delegated Prefix.

How can an Advertised Prefix include the Delegated Prefix ... except, perhaps, in the corner case that they are equal?

> On Mar 18, 2015, at 4:04 AM 3/18/15, Pierre Pfister <[email-masked]> wrote:
> 
> Hello Ralph, 
> 

Your new text has dropped the requirement for reliability.  Is that OK?

> Any device implementing the algorithm. May be a host, a router, a human... I mean, the algorithm is not specific to IP, so it may be anything.

For completeness, I suggest adding that definition to the "Terminology" section.
> It is necessary, but out of the scope of the document.

Do you mean the exact way in which the identification is accomplished?

> Because it strongly relies on the context, e.g., whether links are numbered or not, or the type of messaging.

For completeness, I suggest adding text to the effect that "each Shared Link must have a unique identifier and all nodes must agree on the way in which Shared Links are identified".

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 18 Mar 2015 15:27:17 +0100

Ralph,

> How can an Advertised Prefix include the Delegated Prefix ... except, perhaps, in the corner case that they are equal?

Well, there are even more cornered cases. Imagine you have a /56 DP, and you assign a /60. And suddenly the /56 DP dies and is replace by a single /64. Then you may have the assigned /60 containing the /64 DP.

The node assigning the /60 *will* un-assign it as soon as it gets the information that the /56 died. But in the meantime, other nodes should wait before assigning a prefix from the /60.

> Your new text has dropped the requirement for reliability.  Is that OK?

I actually noticed that right after sending the email. Good point. I added it.

> For completeness, I suggest adding that definition to the "Terminology" section.

I take good note of that. Will add it if I got other similar comments.

> Do you mean the exact way in which the identification is accomplished?

Yes. There could be so many ways that can be done. Not relying on unique link identifiers.

> For completeness, I suggest adding text to the effect that "each Shared Link must have a unique identifier and all nodes must agree on the way in which Shared Links are identified".

It is not how it works in HNCP.
In HNCP, we identify interfaces, not links. So links don’t have unique identifiers. We use interface identifiers and neighboring relationships in order to identify links. HNCP digests the information and gives it to the PA code. At that point, the link is identified by its position in memory (pointer). So there is no strong need for unique link identifier.

Thanks,

- Pierre