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
>