Re: [Roll] Fwd: Re: [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope
Robert Cragie <robert.cragie@gridmerge.com> Wed, 07 January 2015 12:00 UTC
Return-Path: <robert.cragie@gridmerge.com>
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 C3DED1A6FD5 for <roll@ietfa.amsl.com>; Wed, 7 Jan 2015 04:00:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 lKMMKRStuXnq for <roll@ietfa.amsl.com>; Wed, 7 Jan 2015 04:00:42 -0800 (PST)
Received: from mailscan1.extendcp.co.uk (mailscan27.extendcp.co.uk [176.32.228.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2015E1A0071 for <roll@ietf.org>; Wed, 7 Jan 2015 04:00:41 -0800 (PST)
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1Y8pHx-0004U0-VM; Wed, 07 Jan 2015 12:00:37 +0000
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1Y8pHv-0000SB-Tl; Wed, 07 Jan 2015 12:00:37 +0000
Received: from host86-167-170-172.range86-167.btcentralplus.com ([86.167.170.172] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Y8pHt-0007GN-AX; Wed, 07 Jan 2015 12:00:33 +0000
Message-ID: <54AD1FDA.6040207@gridmerge.com>
Date: Wed, 07 Jan 2015 12:00:26 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks <roll@ietf.org>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, consultancy@vanderstok.org
References: <2cae0814be28bb83918ebd2d89d86182@xs4all.nl> <5498334B.5010205@joelhalpern.com> <0fab60ad65358f6d52d58a2ac9ba3cc5@xs4all.nl> <54999605.1010402@joelhalpern.com> <013101d0227d$c9f04ed0$5dd0ec70$@olddog.co.uk>
In-Reply-To: <013101d0227d$c9f04ed0$5dd0ec70$@olddog.co.uk>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms080804040200040909000902"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/qhtFk6mefe7aJ_y4x-deOHflpEI
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: robert.cragie@gridmerge.com, 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: Wed, 07 Jan 2015 12:00:51 -0000
I agree with Adrian's assessment. "Administratively configured" is loosely defined and it is not a black and white case. With regard to the draft, the configuration (i.e. presence/absence) of MPL interfaces in the node implies the scope and thus can be considered "administratively configured" in that it is not automatically derived but implies by a manual configuration. I agree it does need some clarifying text though. Robert On 28/12/2014 09:08, Adrian Farrel wrote: > 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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >
- [Roll] [roll] #167 (admin-local-policy): Not matc… roll issue tracker
- Re: [Roll] [roll] #167 (admin-local-policy): Not … peter van der Stok
- Re: [Roll] Fwd: Re: [roll] #167 (admin-local-poli… peter van der Stok
- Re: [Roll] Fwd: Re: [roll] #167 (admin-local-poli… Joel M. Halpern
- Re: [Roll] Fwd: Re: [roll] #167 (admin-local-poli… Adrian Farrel
- Re: [Roll] [roll] #167 (admin-local-policy): Not … roll issue tracker
- Re: [Roll] [roll] #167 (admin-local-policy): Not … roll issue tracker
- Re: [Roll] Fwd: Re: [roll] #167 (admin-local-poli… Robert Cragie