On Tue, Oct 24, 2017 at 06:43:21PM +0200, Eliot Lear wrote:
> Giid evening Juergen,
>
>
> On 10/24/17 5:51 PM, Juergen Schoenwaelder wrote:
> >
> > What you describe seem to be different policies. Are you saying that
> > these different policies are bad or a huge management problem and
> > hence we hard-code a default policy that is considered "good" in most
> > situations? If you say removing the implied default rules results in a
> > management burden, what is the reasoning?
>
> Here is a worst case scenario, Juergen: suppose you have 600 different
> types of device on your network and each manufacturer has implemented
> its own class for DNS support. That would mean that the network
> administrator would essentially have to populate 600 classes. Better to
> have a single class, given its commonality. There are very few such
> common services on a network, but there are presumably one or two others
> that will come to be, and thus the ability to extend this list over time.
[...]
> Make sense?
Likely but I guess I have to do more reading to understand what
'populate classes' means for the network administrator...
[. . . . ]
Done some more reading. It is still unclear to me what 'populate
classes' means.
Some general comments (now that I read the ID):
- s/only"accept"/only "accept"/
- the definition of tree diagrams is being moved from
[I-D.ietf-netmod-rfc6087bis] to [I-D.ietf-netmod-yang-tree-diagrams]
- I read:
Great care should be used when invoking the controller class. For
I am not sure what it means to invoke a controller class. So far, I
thought that a 'controller class' is simply a set of IP addresses
belonging to controllers. Hm.
The other module abstracts away IP addresses into certain classes
Controller: Devices that the local network administrator admits to
the particular class.
I guess I am confused by the usage of the word 'class'; the word
seems to be used in different contexts with different meanings and
hence I also confused what populate classes may mean.
- Should the titles of 7.1 and 7.2 be changed to src-dnsname and
dst-dnsname to align with the YANG definitions? Or should the text
in 7.1 and 7.2 not simply become part of the description of
src-dnsname and dst-dnsname?
- Likely a wording issue:
Four of "acl" liste entries that implement default MUD nodes is
listed below.
Did you mean:
Four "acl" list entries that implement default MUD nodes are
listed below.
Back to the thread, which rule does appendix B with the 'default MUD
nodes' really play?
(a) Are these MUD rules that are assumed by a controller to be always
there even if they are not?
(b) Or are these a set of rules that manufacturers may include in
their MUD files?
I assume it is (a) but I find the text not entirely clear. The first
sentence reads like these rules are automatically considered to be
there (by the controller) but the second sentence says that a
manufacturer can overwrite this if necessary. Well, the sentence are
not explicit about which entity is doing what.
[...] This is considered the default
behavior and the ACEs are in effect appended to whatever other "ace"
entries that a MUD file contains. To block DNS or NTP one repeats
the matching statement but replaces the "forwarding" action "accept"
with "drop".
So why is (b) not workable and (a) required?
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>g
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
