Re: [homenet] Alvaro Retana's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)

Juliusz Chroboczek <> Wed, 18 July 2018 14:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50BDB12F1A2; Wed, 18 Jul 2018 07:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U6zYVPRwhYVO; Wed, 18 Jul 2018 07:17:15 -0700 (PDT)
Received: from ( [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52407130DFF; Wed, 18 Jul 2018 07:17:15 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/relay1/75695) with ESMTP id w6IEGRUl010784; Wed, 18 Jul 2018 16:16:27 +0200
Received: from (localhost []) by (Postfix) with ESMTP id 255B0EB22E; Wed, 18 Jul 2018 16:17:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10023) with ESMTP id wdk_UPSxghBX; Wed, 18 Jul 2018 16:17:08 +0200 (CEST)
Received: from (unknown []) (Authenticated sender: jch) by (Postfix) with ESMTPSA id E1FCDEB22D; Wed, 18 Jul 2018 16:17:07 +0200 (CEST)
Date: Wed, 18 Jul 2018 16:17:07 +0200
Message-ID: <>
From: Juliusz Chroboczek <>
To: Alvaro Retana <>
Cc: "The IESG" <>,,,, Barbara Stark <>
In-Reply-To: <>
References: <>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 ( []); Wed, 18 Jul 2018 16:16:27 +0200 (CEST)
X-Miltered: at korolev with ID 5B4F4BBB.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5B4F4BBB.002 from<>
X-j-chkmail-Score: MSGID : 5B4F4BBB.002 on : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <>
Subject: Re: [homenet] Alvaro Retana's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Jul 2018 14:17:18 -0000

> I do have some non-blocking comments:

Thank you very much, Alvaro.

> (1) I think that this document walks a fine line when Normatively
> referring to Appendix A in rfc6126bis given that it is an informative
> appendix.

Fixed to use non-normative language, as you suggested.

> (2) This reminds me; please use rfc8174 template (for Normative language).

Done, sorry.

> (3) The Non-requirements sections (2.2/3.2) are confusing to me.  Maybe it's
> the "negative logic"...

I've renamed "non-requirements" to "optional features" -- NR1 is now OPT1.

> NR2, for example, is worded as a requirement that was considered, and
> the rationale explains why not: an "implementation of Babel MAY include
> support for other extensions"


> (3.3.1) NR3 -- The text says that the requirement not considered
> (non-requirement) is such that "an HNCP node that receives a DHCPv6
> prefix delegation MAY announce a non-specific IPv6 default route", but
> the rationale says that "announcing an additional non-specific route is
> allowed".  I'm confused.  Is announcing the additional route ok, or not?
> Is it ok to assume that optionally advertising the additional route is
> ok?  If it's allowed, then why is this a non-requirement?

This is hopefully clear now -- announcing the non-specific route is an
optional feature.

> (3.3.2) For NR4, is the non-requirement, i.e. one that was not
> considered, that the source-specific route SHOULD NOT be announced?
> This piece is also confusing to me because the rationale says (at least
> the way I read it) that it may be ok to advertise.  It seems to me that
> the text is saying that in fact the route SHOULD NOT (or even MUST NOT
> be announced)...which brings me to the question: what is the requirement
> that was not considered?  What am I missing?

I've re-read the section, and I think I'm going to leave the current
wording.  The intent is:

  - we don't recommend you do it, since it makes your network more
    complex with no benefits we can see;
  - however, it won't break your network, so if you've got a good reason
    we didn't foresee, it's not forbidden.

It is my understanding that this fits pretty well the meaning of SHOULD

-- Juliusz