Re: [Roll] Fwd: Re: [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 28 December 2014 09:08 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03581ACEDB for <roll@ietfa.amsl.com>; Sun, 28 Dec 2014 01:08:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
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 e1GzrBkiV8TW for <roll@ietfa.amsl.com>; Sun, 28 Dec 2014 01:08:05 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EB81A0233 for <roll@ietf.org>; Sun, 28 Dec 2014 01:08:03 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBS9813m019101; Sun, 28 Dec 2014 09:08:01 GMT
Received: from 950129200 (089144210161.atnat0019.highway.a1.net [89.144.210.161]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBS980i4019071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2014 09:08:01 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Joel M. Halpern'" <jmh@joelhalpern.com>, <consultancy@vanderstok.org>, <roll@ietf.org>
References: <2cae0814be28bb83918ebd2d89d86182@xs4all.nl> <5498334B.5010205@joelhalpern.com> <0fab60ad65358f6d52d58a2ac9ba3cc5@xs4all.nl> <54999605.1010402@joelhalpern.com>
In-Reply-To: <54999605.1010402@joelhalpern.com>
Date: Sun, 28 Dec 2014 09:08:03 -0000
Message-ID: <013101d0227d$c9f04ed0$5dd0ec70$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJI/7OLDlTF41nk7gcK/y72upR0VgHjCxusAVIxm4ABboW6G5uN2z+g
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21206.006
X-TM-AS-Result: No--23.816-10.0-31-10
X-imss-scan-details: No--23.816-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtHoSitJVour/QPZZctd3P4B1KoSW5Ji1XtMOjKUxCZwr4Ya XGWS53EtzCcwoePov91vm+yDr9EXkt5ZY75Y7Tbeww5lzZPqy6UQtuqs6BbPJ2vCgbU1auyVvL4 BuAuBsSkvp8M1kuFRq8TpSUFbWSmY7bzFTf/STMpbuDP8ZuCmXjQAp53S718Hv+26ZYWzwkJ5L2 Bpc0g4FU1i8No7236cXEGAbuaD8OXsrfmvTLX/nq73FVUimLHPhA0VjIpLz69PtLhlThdPEIN2p Mn0FcvGIHvHLq6y9SYh2g+vUv+I1Xsk5ijHlPQNXhKwXj03jsBFwwTiVVDSS9hxLDhMiTYXROXa pu6XX6SBjqMA8l05bjeT288mssTUE2ZRbV2rc3Epa6LJktEjgAuK1hIitSIHW+jwVKpqvlLFSSE Uw76he9fL1aQHfEsz+6bI4L940xwyZi98qxHMyPKUR83BvqIteJ1OirYwzAP0Sl72zvn8E8HQPY 9gF7ZMDBD37DJ+PFi3DO15nGjZ07rCfWg2KQ28lTsGW3DmpUt5y+Nu7/EOOkiO8DX9hL7Rvb4+3 z1qe64jxAElV3kh9pPwtSeaJxgGQrA7SYdNSRP0hv/rD7WVZNFqG4/BpDVaGfvHtnLRItvbBBOH LZEaSCuPUjbSJUmas3m4RuLBjYg31PP76HdjIQhWgIsZuXlPEtdrY/Wb3fMNht78/JfyBDIKIy6 kcPuwfwPEe5pI6+mPdResNmQLt1GGCYEVy9x6oxWB033D5MJHRJfU7CVkWuML255sueyGsxEmql 4PhxxpkXmrE6Fyz9ycg6BlL+PIol3YK5SmaeeeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0=
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/9HR7uRgbzxU13TBay1cts8nujuc
Subject: Re: [Roll] Fwd: Re: [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Dec 2014 09:08:08 -0000

To reduce this to the most trivial (and put it in IPv4 terms)...
Is the configuration of 127.0.0.1 "administratively configured" as the loopback
address?
Clearly no human intervention is needed to make it happen, yet there is no
"process" that is run.

I think the 4291 quote is not very helpful since it defines "administratively
configured" as "not automatically derived." In particular, an NMS might be
unsupervised and include software that issues addresses as if it were a human
making configuration choices. That is clearly "automatic" yet still qualifies as
"administratively configured" in my mind.

This document is trying to use a different definition of "administratively
configured" as Peter has stated. I don't believe this has to be derived from
4291, but perhaps it should be clearly stated in this document as he has
offered.

Peter/authors: you have some minor edits to do, and perhaps you can work up a
clear definition and include it early in the document with a statement like "In
this document, the term administratively configured is used to mean..."

Cheers,
Adrian

> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: 23 December 2014 16:19
> To: consultancy@vanderstok.org; roll@ietf.org
> Cc: Adrian Farrel
> Subject: Re: Fwd: Re: [roll] #167 (admin-local-policy): Not match the
requirement
> for administrative configuration of the admin-local scope
> 
> Looking at that quote, I can not see how a behavior that the device
> exhibits without any human intervention can possibly be
> "administratively configured, i.e., not automatically derived" since
> what you are defining is an automatic derivation process.
> 
> I Suppose if you had a knob with two settings, one of which was
> "admin-local <== realm" and one of which was "admin-local <== this
> procedure" you would meet the minimum requirement of the text you quote.
>   That at least would have a human cause something.  In the document as
> written, I do not see a human agent.
> 
> Yours,
> Joel
> 
> On 12/23/14 3:52 AM, peter van der Stok wrote:
> > Hi Joel,
> >
> > There has been a lot of discussion on the roll mailing list of what
> > administratively configured means.
> > A message on the roll mailing list from Michael Richardson summarizes a
> > meeting we had on the subject, and probably cuts to the core of your
> > argument as well.
> > See:
> > http://www.ietf.org/mail-archive/web/roll/current/msg08335.html
> >
> > In particular:
> > <quote>
> > The origin of the second mis-understanding was that the text in
> > multicast-scopes (and rfc 4291) says:
> >
> >           Admin-Local scope is the smallest scope that must be
> >           administratively configured, i.e., not automatically derived
> >
> > The understanding of "administratively configured" for many people
> > implies truck rolls, or ssh logins or router CLI commands.  It was
> > only when this assumption was clearly articulated that the origin of the
> > conflict became clear to all parties.
> >
> > The new understanding is that "administratively configured" is not
> > limited to the things that a human did it, but rather includes any
> > processes or operations that a human (including an IETF document) might
> > cause.   The intent of multicast-scopes is not to limit ways that
> > scopes 4+ can be determined, but to clarify that scopes <=3 are *not*
> > intended to be defined by a physical (or physical-like) topologies.
> > </quote>
> >
> > Does this indeed address your issue?
> > And, do you want me to site the explanation of administratively
> > configured in the draft?
> > accompanied by text that the proposed policy is a default policy.
> >
> > Greetings,
> >
> > Peter
> >
> > Joel M. Halpern schreef op 2014-12-22 16:05:
> >> There are two issues intertwined here.
> >> First, the spec you point to says that the behavior shall be
> >> administratively configured.  So we need to recognize the conflict
> >> between that assertion and the effort to define an automated policy.
> >> What I had thought on my previous reading was that you were resolving
> >> the conflict by having a small number of knobs which guided an
> >> automated behavior.
> >>
> >> If I am reading your comments properly, what you are doing is defining
> >> a default policy, without any administrative configuration.  If so,
> >> you need to do two things:
> >>
> >> 1) You need to identify that you are violating the underlying RFC in
> >> order to simplify operations.  At that point, it would be up to the
> >> community to decide if that is acceptable.  I would expect such a
> >> decision to be clearly identified in the last call.
> >>
> >> 2) You need to describe the policy you want to implement as the
> >> default policy.
> >>
> >> With regard to item 2, the policy in the document or the policy you
> >> propose here are both defensible.  The question would be what policy
> >> the working group wants to enforce.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 12/22/14 2:21 AM, peter van der Stok wrote:
> >>>
> >>> Hi Joel,
> >>>
> >>> Thanks for pointing this out.
> >>> After some thought, the best solution seems to embed the MPL admin local
> >>> scope within the zone concept.
> >>> I propose the following addition:
> >>>
> >>> MPL4 messages remain bounded within a zone. Consequently, MPL4
> messages
> >>> cannot be routed between interfaces belonging to different zones.
> >>> For example, consider a router with 5 interfaces where interfaces A and
> >>> B beloing to zone 1 and interfaces C,D, and E belong to zone 2.
> >>> Mpl4 messages can be routed freely between interfaces A and B, and
> >>> freely between C,D, and E. However, a MPL4 message MUST NOT be routed
> >>> from Interface A to interface D.
> >>>
> >>> When the concept of zone is unknown or disabled in a router, all
> >>> interfaces belong to the same zone.
> >>>
> >>> This means adding the zone concept to rules of section 4.2, and text to
> >>> relate zone better to MPL4 zone.
> >>>
> >>> Does this address your issue?
> >>>
> >>> If yes, I will make a new draft along these lines beginning January
> >>> 2015.
> >>>
> >>> Greetings,
> >>>
> >>> Peter
> >>>
> >>> roll issue tracker schreef op 2014-12-16 00:19:
> >>>> #167: Not match the requirement for administrative configuration of
> >>>> the admin-
> >>>> local scope
> >>>>
> >>>>  From: Joel M. Halpern <jmh@joelhalpern.com>
> >>>>  Date: 2014-12-16 0:59 GMT+02:00
> >>>>
> >>>>  Major issues:
> >>>>      There seems to be a disconnect between the notion of
> >>>> administratively
> >>>>  configured and the behavior described in this draft for admin-local
> >>>>  multicast scope.  As far as I can tell, the forwarding behavior
> >>>> described
> >>>>  here has no mechanism for administratively configuring the
> >>>> administrative
> >>>>  boundary.  The only knob that is used is PROACTIVE_FORWARDING,
> >>>> which is
> >>>>  used for intra-realm multicast forwarding.  Thus, if you have a roll
> >>>>  multicast router with two interfaces in one realm and two
> >>>> interfaces in
> >>>>  another realm, in order to provide realm multicast services for each
> >>>>  realm, this router according to this draft will always forward
> >>>> admin-local
> >>>>  multicast messages between the two realms.  That does not seem to
> >>>> me to
> >>>>  match the requirement for administrative configuration of the
> >>>> admin-local
> >>>>  scope