Re: [homenet] Alvaro Retana's Discuss on draft-ietf-homenet-babel-profile-06: (with DISCUSS and COMMENT)
Alvaro Retana <aretana.ietf@gmail.com> Thu, 10 May 2018 13:25 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE99712D969; Thu, 10 May 2018 06:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oaVW1rVHvN1; Thu, 10 May 2018 06:25:51 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E957712EB05; Thu, 10 May 2018 06:25:50 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id v2-v6so1738315oif.3; Thu, 10 May 2018 06:25:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=3OKrkL+XbNeHpTUv7+hLqPiFcHp2Ar2FIuk5ymD83pQ=; b=N2BDlSNuzogLdVpVoak+Z2OUUAN0NTmZaeqfld8UVPFgxk5H2Vq1FWchtnm1eT6LvO 3QiR2QJtG2fEY53UPw2rKwGj6ah7LPFcyuAZ4VGMsL04eO7m1fSDjfXfE/Cz5gg7b6MO UT43WVUjeq4imKA4aWeCNmtNnKtAE7+L7uvkztkDwPStcoy1kCs8CyuFyyvSC933uNVQ RTEnwntapDFxMpnjJo6W02w/VpB5nAK11yGy7tLcBt8L+v7l1hdD7nIRIoT9vWc1CIe4 hVmA5ML+FAXvNIAwv1Osgxb1b5/H7G0nMAsUejxWF4Rbg/PIRNGnb8SvTcLRiqznil/0 2QWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=3OKrkL+XbNeHpTUv7+hLqPiFcHp2Ar2FIuk5ymD83pQ=; b=Jhtd4ReCKqxIOhtIl0K3a1gZQTnZ8RVcthXXVb3PH+8qICJOuY0qMllDcnHw//45l2 lrgI0lo3FP/hSbrMldnCx44nB7/bZLOVikNakWyU4pVkIR0avNvog9my5+di06Gha1UQ bsY2w7q2fEMRGSEYSVQVUXUl5EIzsTCgA1SoUC6CygmOIzn9hDATLqbJqJoMjo6YKcqs 1g0M8ar6lVwTxtb8Sj+OdwHG5m7NQ9QeSHJ/T5NNB+FNoU6GlUbCTmJNOLVHqDkJ9wF3 rJrpc/FrGqDqK97NF8eSxDZjXEuBlM3Bv0ZHbGeAi+ap3WN1nzL/j8B5b86q0IQhg0iw 6o/w==
X-Gm-Message-State: ALKqPwcTfWwuAcXezNEz47jlqWjrQlU5aZU6WKGsiY4yZLMNKvkV1MhM kAaFSXibDthZYA5Xw/SHExfSVIabXF5ySelWcG4=
X-Google-Smtp-Source: AB8JxZoEepcRmjBWlcVXMtAKdvRDnwx97+KlxxDbZSpd0AuiPDqNsnq2Iy+kCX3co/9fjUs721+Vw7E7gbenDIJSCPA=
X-Received: by 2002:aca:f141:: with SMTP id p62-v6mr827351oih.80.1525958750280; Thu, 10 May 2018 06:25:50 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 10 May 2018 06:25:49 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDAB966@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <152588337024.3994.6537408594032636016.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DDAB966@GAALPA1MSGUSRBF.ITServices.sbc.com>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Thu, 10 May 2018 06:25:49 -0700
Message-ID: <CAMMESsycyMjV9gFY_+6DdMHDGvtaEjMBmQ0WuJz3r2Y-UBze4w@mail.gmail.com>
To: "STARK, BARBARA H" <bs7652@att.com>, The IESG <iesg@ietf.org>
Cc: "terry.manderson@icann.org" <terry.manderson@icann.org>, "homenet@ietf.org" <homenet@ietf.org>, "homenet-chairs@ietf.org" <homenet-chairs@ietf.org>, "draft-ietf-homenet-babel-profile@ietf.org" <draft-ietf-homenet-babel-profile@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000040a37e056bd9f502"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/MU7GHeQKtmKEfArUx0yADshVKU4>
Subject: Re: [homenet] Alvaro Retana's Discuss on draft-ietf-homenet-babel-profile-06: (with DISCUSS and COMMENT)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 13:26:00 -0000
Barbara: Hi! Thanks for the response! This (along with the confirmation from Stephen and Terry) was all the confirmation I wanted. I agree with your points and the rationale. I’m clearing my DISCUSS. Thanks! Alvaro. On May 9, 2018 at 6:19:56 PM, STARK, BARBARA H (bs7652@att.com) wrote: Hi Alvaro, Thanks for the comments. I agree we need to make sure the community is comfortable with the decision. I've inserted my comments in-line. Barbara > I would like to DISCUSS about the Intended Status of this document -- with > the Chairs and AD. > > I have to confess that I haven't been following the homenet WG as closely as > I > probably should have. Hopefully that means that the topic below has been > discussed and documented already, making this DISCUSS easy to resolve. > > Back in 2015, the then-Chairs and the AD posted a note titled "Routing Design > Team outcome and next steps"[1]; in it, they declared "rough consensus that > Babel[*] shall be the “mandatory to implement” routing protocol for > Homenet > routers, albeit only on an Experimental basis at this time...we solicit > Experimental Internet Drafts to document Homenet-specific profiles of any > applicable routing solution and to report results of any relevant > experimentation and implementation. We expect that this decision will be > revisited in a future Standards Track document based on specifications and > running code available at that time." > > My interpretation of the above text is that Babel is MTI, <bhs> There is no draft or published RFC that proposes making Babel MTI. The language of the quoted text is a bit odd (a MTI experimental protocol?), which makes it open to interpretation. My interpretation differs from yours. My interpretation was that people actively working to create (experimental) code for homenet stacks needed to implement Babel if they wanted to test out interoperability with other stacks. Those experimental stacks were created. Interoperability was tested. We have running code and a standards-track Babel draft (rfc6126bis) now. I don't believe a WG discussion has the ability to make a protocol MTI in the absence of a published RFC that states it is MTI in some context. No draft exists or has ever been submitted to propose making Babel MTI. > but that the work > (documents) will be Experimental...and that this decision could change in the > future (most likely towards confirming and moving to the Standards Track). > This document was originally adopted as Experimental. I didn't find an > explicit discussion on the list about changing that original overall direction, > nor another declaration by the Chairs/AD. I did find find a thread in which > one of the Chairs (Barbara) asked about the status for this document (and > this document only)[2]; the initial question was framed around the references > being Standards Track documents (HNCP and rfc6126bis) -- just one answer came > back (from the author of this document)... > > I'm treating this point as a DISCUSS because I think that the WG consensus > may > have not been determined to change the original declaration from the > Chairs/AD > (from 2015). In my interpretation of that original declaration, moving Babel > to the Standards Track means a recognition that it will be *the* protocol > going > forward (which changes that initial "only on an Experimental basis at this > time" phrase), is something that should be discussed explicitly, and not just > in light of this one document. That is the part that I haven't seen. <bhs> I consider the lack of alternate proposals as implying there are no technical objections to Babel being *the* protocol. It's hard not to be *the* protocol when you're the only protocol. Whether or not the homenet-babel-profile is Standards track, it is *the* protocol in the absence of others. And after 2 years of no other proposal being submitted and multiple Babel profile implementations, I suspect WG participants might push back heavily against adding another protocol. Another protocol would face a serious uphill battle. And this would be true independent of the status attached to the Babel profile. Two years is plenty of time to have submitted a draft. But there is nothing in the language of the Babel profile that would preclude submission of another protocol profile. > I note that in the conclusion of the thread about the status of this document > [3] Barbara does include reasoning that may result in changing the original > declaration (as does the Shepherd writeup), for example: "there exist > multiple, > interoperable implementations" and "no drafts proposing other homenet > routing > protocol profiles have been submitted"...but those points don't seem to > have > been considered/discussed by the WG (they were not in the original > message and > I didn't find another thread -- I also looked at the minutes of the last couple > of IETF meetings). > > To be clear, I have no objection with Babel being used in homenet > applications, > or with it being the Standard protocol. My point here is that it is not clear > to me that the WG explicitly reached consensus to change the declaration > from > the Chairs/AD. I will be happy to clear this DISCUSS when the Chairs/AD > point > me to the discussion that I missed, or simply tell me that the declaration from > 2015 is no longer valid and that the WG knows, or that they believe that the > thread discussing this document is enough to call consensus...or something > to that effect. I did consider the emails you pointed to as having adequately advised the WG of the proposed change and invited discussion and/or objection. I did also get a private email response pointing to the 2015 decisions you noted but not objecting to the proposed status change. I discussed with Stephen (co-chair) and Terry (AD) who both indicated they were satisfied with the lack of objection to my emails. It is my belief that members of the WG are very, very aware (many still bear deep scars) of the 2015 discussion. They are also aware that the WG has been open to receiving other routing protocol profile proposals for 2 years now, and that none has been received. Several people told me privately they were glad the status was being changed so we could get this over with (and that homenet was already in danger of being obsolete and losing everyone if it couldn't move on). They didn't want to say *anything* on the email thread, for fear that it might actually trigger re-opening the discussion in all it's glory. There is a strong desire not to have that discussion again. I do believe that, given the hyper-awareness of the 2015 discussion, the WG knew what it was agreeing to (or not objecting to). I believe the WG is knowingly saying it wants to move on. Naming and security need solutions, and we need to be working on those. But if you still think I need to explore this some more with the WG, I will. Barbara > [1] https://urldefense.proofpoint.com/v2/url?u=https- > 3A__mailarchive.ietf.org_arch_msg_homenet_kiI7pIYfpgT2Qrfx1VBAwng7- > 5FQY&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC- > 8sc8SY8Tq4vrfog&m=LS5wCRK83QbSm0A7c-uQ50-sORylXeseG- > zQI_D8ABU&s=3czWjkOM36nRroRWTFHYjcWEZF_WsTqCHLjLrGBRxmk&e= > [2] https://urldefense.proofpoint.com/v2/url?u=https- > 3A__mailarchive.ietf.org_arch_msg_homenet_5L5WYN14gDCamP7qlknJmW > keU5M&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC- > 8sc8SY8Tq4vrfog&m=LS5wCRK83QbSm0A7c-uQ50-sORylXeseG- > zQI_D8ABU&s=TntrJlZrFtZU8GHp86i_BfjU5BPtSn5lqHwDVSEHfv0&e= > [3] https://urldefense.proofpoint.com/v2/url?u=https- > 3A__mailarchive.ietf.org_arch_msg_homenet_35EU8oBr8hunvvSRYUStypZI > PVU&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC- > 8sc8SY8Tq4vrfog&m=LS5wCRK83QbSm0A7c-uQ50-sORylXeseG- > zQI_D8ABU&s=8kr7ZyZhA8zZEKfNDbVouzU-BmWT-t_WOgi7WcZKYkM&e= > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (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. In general, > it does a good job at it -- I do, however, have one nit: "The algorithm > described in Appendix A of RFC 6126bis MAY be used." I think that changing > that to something non-normative would be good, perhaps something like > "Appendix > A provides an example of an algorithm..." or simply s/MAY/may > > (2) This reminds me; please use rfc8174 template (for Normative language). > > (3) The Non-requirements sections (2.2/3.2) are confusing to me. Maybe it's > the "negative logic"... > > (3.1) What do these non-requirements represent? Are they requirements > that > were considered at some point, but discarded? Using rfc2119 language adds > to > the confusion -- consider describing these non-requirements not using it. > > 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"...this is not a requirement because "with the exception of > source-specific routing, no extensions are required". Ok. > > (3.2) Are implementers to interpret that the converse is true/expected? In > the > case of NR2, is a true interpretation that implementations SHOULD NOT > include > support for other extensions? IOW, while the option of other extensions is > not > a requirement, is not having them one? > > (3.3) The non-requirements in §3.2 seem a lot more confusing to me: > > (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? > > (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? >
- [homenet] Alvaro Retana's Discuss on draft-ietf-h… Alvaro Retana
- Re: [homenet] Alvaro Retana's Discuss on draft-ie… Ted Lemon
- Re: [homenet] Alvaro Retana's Discuss on draft-ie… STARK, BARBARA H
- Re: [homenet] Alvaro Retana's Discuss on draft-ie… Stephen Farrell
- Re: [homenet] Alvaro Retana's Discuss on draft-ie… Terry Manderson
- Re: [homenet] Alvaro Retana's Discuss on draft-ie… Alvaro Retana