[nmrg] [Fwd: Re: Fwd: [irsg] IRSG Review for draft-irtf-nmrg-an-gap-analysis]

[Brian E Carpenter <[e-mail]>]

Forwarded to the group with permission:

-------- Original Message --------
Subject: Re: Fwd: [irsg] IRSG Review for draft-irtf-nmrg-an-gap-analysis
Date: Thu, 11 Dec 2014 11:27:36 +1300
From: Brian E Carpenter <[e-mail]>
Organization: University of Auckland
To: Lisandro Zambenedetti Granville <[e-mail]>,  [e-mail],  Lars Eggert
<[e-mail]>, Kevin Fall <[e-mail]>

Hi Kevin, and colleagues,

A new version is posted at http://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis-03 .

>>> Data: 2 de dezembro de 2014 21:18:01 BRST
>>> De: Kevin Fall <[e-mail]>
>>> Para: "Eggert, Lars" <[e-mail]>
>>> Cc: "Internet Research Steering Group \([e-mail]\)" <[e-mail]>
>>> Assunto: Re: [irsg] IRSG Review for draft-irtf-nmrg-an-gap-analysis
>>>
>>> Hi.
>>> I believe this document needs some work.  My comments are here:

Thanks for the very useful review. Where we don't think we have fully
answered your point and/or we significantly disagree, there are
comments below. No comment means we think we have fixed the point.

>>> In section 3.1.1:
>>>
>>>
>>> "originally" evidently takes us to a time after
>>> subnetting had been established.  But really, when we first had
>>> these IP addresses, there weren't even these subnets.
>>>
>>> I wouldn't really agree that it is "difficult to separate IP address
>>> management from DNS management".  The management of the DNS
>>> hierarchy in operation (delegations, servers, records, etc)
>>> covers a lot more than the address assignment aspects.  More
>>> appropriate may be to say something such as "DNS mappings typically
>>> need to be appropriately synchronized with IP address assignments".
>>>
>>> For the "address management tools", examples would help.
>>> Some "tools" keep the addresses and DNS information already synchronized.
>>> Also to say, "These are... centralised and far from autonomic type of
>>> solution" seems unnecessarily perjorative.  Is something like dnsmasq
>>> "far from autonomic"?

We draw a distinction between 'automatic' and 'autonomic', but anyway
we have rephrased this, and added a reference to avoid duplicating
discussion that's in an existing RFC.

>>> The comment "how this topic is to be handled in home networks is still
>>> an open question" should have some sort of reference describing the
>>> issue.
>>>
>>> I am surprised to see no reference to RFC2462.  I think it needs to be
>>> discussed.  RFC3041 also should receive some attention.

Earlier, we had a short discussion of this topic that we removed,
but now we have put something back in again, with current citations.

>>> I find the last paragraph of this section needing attention.
>>> Why is this DDNS capability a "complication"?  What makes it
>>> an "autonomic approach"? (i.e. to what? and versus what alternative?)
>>> What are the "coexistence issues"?
>>>
>>> Section 3.1.2
>>>
>>> There already existed dynamic routing within ARPANET in 1969.
>>> See IEEE Trans on Communications Dec 1978.  I believe the
>>> comment of "as soon as the network was large enough for manual
>>> configuration of routing tables to become difficult" in not
>>> what happened.  That comment is true and applicable, however, for DNS.
>>>
>>> There is, of course, much more one can say about routing but it may
>>> not really be needed here.  Recall there are things like ICMP redirects
>>> and router discovery and NHRP that provide various amounts of
>>> "autonomic" operation.

True, but it does seem too detailed for this document.

>>> Section 3.1.3
>>>
>>> Again there is mention of issues wrt >1 prefix on the same subnet.
>>> Please provide a reference for this.
>>>
>>> Section 3.1.4
>>>
>>> Once again "originally" dates to when?  I believe the use of hosts
>>> goes back to HOSTS.TXT (see RFC 608), and I'm not at all certain it
>>> was from a Unix machine this was generated. (possibly TOPS or Tenex or
>>> maybe even MULTICS)
>>>
>>> This section should probably mention mDNS.
>>>
>>> Section 3.1.5
>>>
>>> "early 1990s" -> "the early 1990s"
>>>
>>> Section 3.1.6
>>>
>>> I suspect there is much more to say here, for example the whole
>>> area of IPS systems.
>>>
>>> Does privacy belong in this section?  Is something like Tor autonomic?

It's hard to say anything specific about privacy. One could imagine "Forbid
Tor" or "Use Tor" as policy items. Anyway, we have slightly expanded this
section.

>>> Section 3.1.7
>>>
>>>
>>> "Without any overall controller being involved" seems unclear.
>>> Given that time servers are involved, what is this trying to say precisely?
>>>
>>> The section title seems to broad.  For example, distributed routing
>>> is "merely" a type of "synchronization", right?  Even parts of
>>> routing (leader election) and failover (VRRP) do such things.
>>>
>>> Section 3.1.8
>>>
>>>
>>> This seems like a bit of a manifesto statement.  I'm not sure why
>>> it would be under the subsection titled "Miscellaneous".

Correct. We moved the material to a later section.

>>> Section 3.2.1
>>>
>>> Please define 'Network establishment'.
>>> Does 'architecture' here refer to deployment architecture?  It doesn't
>>> appear to mean protocol architecture.
>>>
>>> Section 3.2.2
>>>
>>> Please include a reference to support the comment that "This is the
>>> source of most network configuration errors."

Couldn't exactly do that, but we have improved the logic.

>>> The comment regarding SDN requires some justification or reference if
>>> it stays in.
>>>
>>> Section 4.1
>>>
>>> I think the assertion that all the existing/prior work on protocols
>>> that support discovery, synchronization or negotiation are too specific
>>> requires some support.

This point has a whole section to itself in one of the Anima WG
submissions, so it seemed better to simply remove it here.

>>> Section 4.2
>>>
>>> So what do you think of efforts like BEEP, TLS, SASL?  How does these
>>> fail to be what you are after?  How about NHDP?

Same comment - analysing existing protocols is a job for Anima.

>>> Section 4.3
>>>
>>> This seems to wander and isn't very specific.  It basically seems
>>> to say that you need to be secure.  Is that all there is to it?

Well, it also says that we need to identify the autonomic control
plane in its own right. We tried to tighten up the language.

>>> Section 4.4
>>>
>>> The first paragraph makes a number of claims without reference.
>>> Supporting reference or evidence should be mentioned.
>>>
>>>
>>> Section 4.5
>>>
>>> I don't understand this section.  In particular, I do not see why
>>> 'autonomic networking' has any different sort if trades than
>>> normal networking with respect to testing and experimentation.
>>> We use simulation and emulation and live testing already.  What
>>> is different here?

"a configuration change could be tested out in the control plane
without actually affecting the data plane." It's true that such a
dry run mode could be implemented in a conventional network
management model such as NETCONF, but in an autonomic setup
it would be part of a closed loop, not involving the NMS
or the operator. It's the closed loop that makes it different.

>>>
>>> Section 4.6
>>>
>>>
>>> Perhaps a philosophical point, but I do not agree with the statement:
>>> "The more knowledge we have, the more intelligent we are."
>>> (see, for example:
>>> https://philosophynow.org/issues/98/Information_Knowledge_and_Intelligence)

Rewritten a bit.

Thanks again

   Brian, Michael, Sheng