Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Juliusz Chroboczek]

After much thought, I have settled on the following:

  Rationale: support for wireless transit links is a distinguishing
  feature of Homenet, and one that is requested by our users.  In
  the absence of dynamically computed metrics, the routing protocol
  attempts to minimise the number of links crossed by a route, and
  therefore prefers long, lossy links to shorter, lossless ones.  In
  wireless networks, "hop-count routing is worst-path routing".

I find the previous version clearer and more informative, but I've read
ISO/IEC 10589, and therefore understand that the author of a Standard
should aim to sound professional rather than indulging in such amateurish
endeavours as being clear or informative.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

>> we are writing a standards document, not a 19th century romance novel
>
> It is a truth generally acknowledged that a single man in possession of
> a good fortune must be in want of a home network.

Ah yes, much better. I for one believe it prudent to adopt this style
for all homenet documents, lest we risk being relegated to the obscurity
of the cold and corporate world of yesteryear ;)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Juliusz Chroboczek]

> we are writing a standards document, not a 19th century romance novel

It is a truth generally acknowledged that a single man in possession of
a good fortune must be in want of a home network.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

>>> This is not the notion that I tried to express, probably badly.  It's not
>>> necessarily the important feature, it's the one that will make people
>>> implement and deploy the protocol stack in the first place.
>
>> Suggestion for '"killer feature" of Homenet': driver for using Homenet
>
> That's good.
>
>>> If you find a sufficiently stately term that covers all of the above,
>>> I'll take it.  (My thesaurus suggests "chieftain", but I tend to favour
>>> "foreman".)
>
>> Suggestion for "our bosses": decision makers
>
> "easy to explain to the decision makers"?  It's okay, but sounds somewhat
> cold and corporate to my (admittedly foreign) ears.  I'll wait a little
> while in case somebody has a better idea.

"masters"
"liege lords"
"jarls"
"overseers"
"(robot) overlords"
"decision-making units"
"callers of shots"
"head honchos"


(As you can see, I tried and failed to come up with something better;
I'd tend to agree that "decision makers" is a bit cold and corporate,
but then we are writing a standards document, not a 19th century romance
novel...)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Juliusz Chroboczek]

>> This is not the notion that I tried to express, probably badly.  It's not
>> necessarily the important feature, it's the one that will make people
>> implement and deploy the protocol stack in the first place.

> Suggestion for '"killer feature" of Homenet': driver for using Homenet

That's good.

>> If you find a sufficiently stately term that covers all of the above,
>> I'll take it.  (My thesaurus suggests "chieftain", but I tend to favour
>> "foreman".)

> Suggestion for "our bosses": decision makers

"easy to explain to the decision makers"?  It's okay, but sounds somewhat
cold and corporate to my (admittedly foreign) ears.  I'll wait a little
while in case somebody has a better idea.

(Since we all seem to be in a chatty mood -- on Tuesday last, I was
teaching virtual memory allocation techniques, and needed a translation
for "eager allocation" as opposed to "lazy".  One student proposed
"allocation zélée".  I'm loving it.)

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[STARK, BARBARA H]

> > Perhaps I could suggest something in the vein of "very important" or
> > "much desired feature"
> 
> This is not the notion that I tried to express, probably badly.  It's not
> necessarily the important feature, it's the one that will make people
> implement and deploy the protocol stack in the first place.

Suggestion for '"killer feature" of Homenet': driver for using Homenet

> > I found the term "bosses" leaving much to interpretation
> 
> This happens to be deliberate.  I am trying to avoid implying too much about
> the organisational structure to which the reader belongs -- the "boss" here
> could be the CIO, but it could be the leader of an Academic project, it could
> be the supervisor of the intern who's implementing Homenet, or it could be
> the Benevolent Dictator for Life of a Free Software project.
> 
> If you find a sufficiently stately term that covers all of the above, I'll 
> take it.
> (My thesaurus suggests "chieftain", but I tend to favour "foreman".)

Suggestion for "our bosses": decision makers
Which applies to all of the example people mentioned, but also spouses, 
significant others, and spoiled children -- who may be more relevant in the 
context of homenet.

Barbara

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Juliusz Chroboczek]

> I too think the rationale is important but the phrasing may be confusing. 
> Being
> a native speaker of U.S. English (and almost fluent in Southern Californiaese
> ;-) I found the colloquialisms confusing.

Being myself a native speaker of an Eastern-European dialect with way too
many postalveolar fricatives, I will be grateful for additional guidance.

> Perhaps I could suggest something in the vein of "very important" or
> "much desired feature"

This is not the notion that I tried to express, probably badly.  It's not
necessarily the important feature, it's the one that will make people
implement and deploy the protocol stack in the first place.

Long-term, the important feature of Homenet is having a clean architecture
for multi-link IPv6 networks.  From the point of view of the end-user,
however, multiple layers of NAT work just as well, so it's not a "killer"
feature.

Short-term, the two visible features are support for multiple uplinks and
support for wireless transit.  No other protocol stack can do either of
these without manual intervention, so these are Homenet's "killer"
features.

I agree that the term might not be familiar to everyone, and I would be
sincerely grateful for help with expressing this notion concisely and
without undue colloquialisms.

> I found the term "bosses" leaving much to interpretation

This happens to be deliberate.  I am trying to avoid implying too much
about the organisational structure to which the reader belongs -- the
"boss" here could be the CIO, but it could be the leader of an Academic
project, it could be the supervisor of the intern who's implementing
Homenet, or it could be the Benevolent Dictator for Life of a Free
Software project.

If you find a sufficiently stately term that covers all of the above, I'll
take it.  (My thesaurus suggests "chieftain", but I tend to favour "foreman".)

> or perhaps even "Corporate" used instead.

Now you're trying to pick a fight ;-)

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Jeff]

Minor issues:


   Rationale: support for wireless transit links is a "killer
   feature" of Homenet, something that is requested by our users and
   easy to explain to our bosses.  In the absence of dynamically

SB> Not sure explicability to your boss counts for much as a basis for
SB> a feature an international standard.

I think this paragraph is helpful for implementors -- it helps people
explain to their bosses why we're bothering with link-quality estimation
when we've done routing protocols with no link-quality estimation for the
last fifty years or so.  (The Fuzzball LSI-11 router had link-quality
estimation, but that was in the 1980s.)  Still, if you find the tone too
informal, I'm open to reformulating.
I too think the rationale is important but the phrasing may be 
confusing.  Being a native speaker of U.S. English (and almost fluent in 
Southern Californiaese ;-)  I found the colloquialisms confusing. 
Perhaps I could suggest something in the vein of "very important" or 
"much desired feature" etc for "killer".  I found the term "bosses" 
leaving much to interpretation and would prefer to see something more 
like "management" or "decision maker", or perhaps even "Corporate" used 
instead.


Jeff Bowden
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Juliusz Chroboczek]

> I am the assigned Gen-ART reviewer for this draft.

Thanks for your comments, Stewart.

>   if implementations use conflicting route selection policies,
>   persistent oscillations might occur.
SB> Is this consistent with the statement earlier in the para that
SB> " Distinct
SB> implementations of RFC 6126bis Babel will interoperate, in the
SB> sense that they will maintain a set of loop-free forwarding paths"?

Yes, it is consistent.  Please see Section 3.6 of rfc6126bis.

In short, Babel guarantees that the forwarding graph remains loop-free
at all times (which is somewhat weaker than what you'd expect -- in
particular, it does not entail that a packet will never pass the same
router more than once).  It does not make any guarantees about the
stability of the forwarding graph if the route selection policy is
completely crazy.

As far as I am aware, the problem of defining the class of non-crazy route
selection policies is an open research problem.  The best we can do, to
the best of my knowledge, is give examples of policies that do not cause
oscillations.

This is not unlike BGP, which does an excellent job avoiding loops, but
does not prevent persisten oscillations in the presence of crazy policies.
Interestingly enough, a numbre of papers indicate that this is not
a problem in the Internet, and that router operators are pretty good at
defining reasonable BGP policies.  I believe the same is true of Babel.

>  Since IPv6 has some
>   features that make implementations somewhat simpler and more
>   reliable (notably link-local addresses), we require carrying
>   control data over IPv6.
SB> Earlier you said that IPv4 also had Link Local addresses, so how
SB> can link local addresses be the deciding selection criteria? Is there
SB> something technically better about IPv6 LL?

No, I didn't -- I'm trying to be consistent, and use LL to mean fe80::/64.
I believe the issue is in Section 1, where I say

   traffic is carried over either link-local IPv6 or IPv4

where what I mean is

   either link-local IPv6 carries traffic, or IPv4 carries traffic.

I'm not a native speaker, and I'll be grateful if you can suggest a better
formulation.

> Minor issues:

>   Rationale: support for wireless transit links is a "killer
>   feature" of Homenet, something that is requested by our users and
>   easy to explain to our bosses.  In the absence of dynamically

SB> Not sure explicability to your boss counts for much as a basis for
SB> a feature an international standard.

I think this paragraph is helpful for implementors -- it helps people
explain to their bosses why we're bothering with link-quality estimation
when we've done routing protocols with no link-quality estimation for the
last fifty years or so.  (The Fuzzball LSI-11 router had link-quality
estimation, but that was in the 1980s.)  Still, if you find the tone too
informal, I'm open to reformulating.

> Abstract

>This document defines the subset of the Babel routing protocol and
>its extensions that a Homenet router must implement, as well as the
>interactions between HNCP and Babel.

SB> HNCP needs to be expanded Both need a reference, but the reference
SB> needs to be expanded i.e. RFC7788 not [RFC7788]

Is this consistent with the last sentence of RFC 7322 Section 4.3?

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet