Thanks Michael. That sounds like you are covering my concerns quite
effectively.
On the IDevID reference, all I think is needed is to change the IEEE
reference to be normative instead of informative. (Or if Toerless'
suggestion is effective in your view, change the text to say that IDevID
is defined in a normatively referenced I-D instead of in the IEEE document.)
Yours,
Joel
PS: Regarding copying i...@ietf.org, I think it is okay to have removed
them now. Anyone outside the WG who wants to know about the
conversation is aware that it is occurring. Because these are IETF LC
comments, the initial comments need to go to the ietf list.
On 8/11/18 10:36 AM, Michael H. Behringer wrote:
Thanks Joel for the thorough review! Sorry for the delayed response, I
was mostly offline on business travel. As Brian, I also took
i...@ietf.org off the cc, please let me know if this is inappropriate,
in which case I repost with that list on.
Inline...
On 10/08/2018 10:00, Joel Halpern wrote:
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-anima-reference-model-06
Reviewer: Joel Halpern
Review Date: 2018-08-09
IETF LC End Date: 2018-08-21
IESG Telechat date: Not scheduled for a telechat
Summary: The document is ready for publication as an Informational RFC.
Clarity would be improved if the minor issues below were addressed.
Major issues: N/A
Minor issues:
Section 2 includes "naming" in the list of services the ANI
provides.
Which surprised me. But then section 3 does not include "naming"
in the
list of services of the ANI in Figure 2 of section 3.1?
Yes, naming is actually required for an autonomic solution. I understand
your concern though, and added it to figure 2 and section 3.1. It's more
consistent, you're right.
In section 3.2, in the second paragraph on where adjacency
information
comes from, the text of the second bullet refers to vendor
redirects.
While I understand that those are an important part of the system
information, they do not appear to create an adjacency? If they
do, then
the term adjacency needs to be better explained in this section.
The first
bullet in the next list says the same thing. My best guess is that
adjacency sometime means actual topological adjacency, and
sometimes means
a more general form of adjacency. As written, I think it will
confuse
readers.
Hmmm... I re-read our text, and I think it describes exactly what we
want to say. :-) So there is clearly a problem.
The original idea was that a new node with factory default settings
needs to be able to find where it should connect. Since a factory
default device cannot have specific information of its final network
placement, the vendor MASA can be set up to provide information to the
new node on where its home network is. I think we're probably in sync up
to here.
Now, our design decision was that this re-direct from the MASA should
not require any other treatment than any other adjacency: It delivers an
IP address to connect to, and to set up the ACP with. From this logic
follows that the re-direct address is also entered into the adjacency
table, and not treated in any "special" way.
So, the real problem is probably the referernce to BRSKI, since this
behaviour is not yet defined there. I suggest to simply remove the
reference to BRSKI at this point. That seems to be the only confusing
bit. And it allows potentially another document in the future to take up
the details. I've taken it out for now. If anyone thinks that's a bad
idea, shout! :-)
IDevID (referenced in section 3.3.1 at least) appears to be a
normative
reference. Devices supporting the Anima Reference Model are
required to
support that, so understanding how to do so seems necessary for
understanding this specification.
I just read the entire discussion on this point, and am unsure what you
would like us to do, or what the problem actually is. Can you be more
specific?
Does section 3.3.2 intend to mandate that devices have persistent
storage
for the LDevID? Or is it trying to say that on power cycle it
stays in
Enrolled state if it retains its LDevID, but goes back to the
Factory
default state if not? (Given that folks have repeatedly said
that these
may be low power devices, I think we need to be clear about what
we are
requiring.)
Yes, your guess is absolutely right. I clarified that now by adding in
the intro of section 3.3 (it affects the state machine in TWO points,
actually):
<t>A device is normally expected to store its LDevID in persistent
storage, to be available after a powercycle event. For device types that
cannot store the LDevID in persistent storage, a powercycle event is
effectively equivalent to a factory reset. </t>
Section 5 starts by saying that the administrator does not have to
configure security. In the very next paragraph it says that a
PKI must be
in place. That clearly requires configuring some security
properties.
Please reword.
I added a little phrase at the end of the sentence which now reads:
<t>An Autonomic Network is self-protecting. All protocols are
secure by default, without the requirement for the administrator to
explicitly configure security, with the exception of setting up a PKI
infrastructure. </t>
Section 6.2 says that all ASA must "follow the same operating
principles".
The general guideliens of what these must cover is then given.
It is
appropriate that this document does not specify the detailed
behavior.
That would go in a standards track document. But there is no
reference to
a draft covering that. So we have text saying that all ASA must
follow
"something", but no reference as to the content of that
"something". Is
this a real requirement? If so, it appears to be unmeetable.
I think the "must" is misleading here. It's not meant to imply that we
have something ready-to-go for this, it's saying: One day, when someone
bites his teeth into this problem, make sure that all ASAs are managed
in the same way.
So, re-phrasing: "Management of ASAs and its interactions with the ANI
should follow the same operating principles, hence comply to a generic
life-cycle management model."
This should be sufficiently clear what we mean, without implying that we
already have a solution. OK?
Nits/editorial comments:
In section 3.2, why would / could an adjacency table track
"validity and
trust of the adjacent autonomic
node's certificate" if all transactions have to verify that
separately
anyway? Why mention it here?
Yes, that doesn't read right. Simplified that to: "The adjacency table
may contain information about the validity and trust level of the
adjacent autonomic node." (deleted the second sentence). Does that work?
In the next to last bullet of the second bulleted list of section
3.2, the
text states that the node will start a "join assistant" ASA.
Could we have
a forward reference to 6.3.1.2 (which then has the necessary
normative
reference)?
Done.
The first use of LDevID in section 3.3.1 should have a forward
reference to
the definition (which I think is section 5.2.)
Done.
Section 3.3.2 in defining when a device is in the Enrolled state
says that
it in the Enrolled state if it has an LDevID. As far as I can
tell, the
added constraint is that it is not currently a member of an ACP.
The text
should include that.
Done.
The third paragraph of section 6.1 refers to the Autonomic nodes
and the
ASAs as "self-aware". I do not know what meaning is being
ascribed to that
phrase. The usage does not seem to correspond to any meaning I can
understood. Can we just remove the sentence? (I suspect that the
intention is to lead to the fact that the functions can advertise
their
capabilities, and negotiate them. We don't need the sentence as
grounding
for that.)
We mean: In a traditional network, a big fat brain knows all the
capabilities and hardware details of all platforms, and decides
centrally which software bits and command lines and other bits and
pieces should go to which node.
In an autonomic network, it is the node itself that knows its own h/w
features and capabilities, and decides how to implement the guidance of
the central brain, which now only issues Intent.
Modified that to:
"<t>Autonomic nodes, and therefore their ASAs, know their own
capabilities and restrictions, derived from hardware, firmware or
pre-installed software: They are "self-aware". </t>
<t>The role of an autonomic node depends on Intent and on the
surrounding network behaviors, which may include forwarding behaviors,
aggregation properties, topology location, bandwidth, tunnel or
translation properties, etc. For example, a node may decide to act as a
backup node for a neighbor, if its capabilities allow it to do so. </t>"
(Laurent - please let me know if you are ok with this change)
While I appreciate the reference to SUPA in section 7.2, the
working group
having been terminated by the AD makes this a difficult topic for
people to
find. Presumably, PCIM should be an actual reference to the
relevant RFC.
Removed SUPA, and left PCIM.
Personal opinion: Section 8 on coordination is too hypothetical
to be
useful to a reader of this document. I think it is better removed.
I appreciate your opinion, but I would prefer to keep it, as background
info. It's clearly labelled with an "*". This piece of the story was
contributed by Laurent and Pierre, who had done a lot of work in this
area, and I really learned a lot from it. Designers of ASAs should
definitely read it. There is a lot of stuff in there that you might miss
without this section.
But, I'm looking at Laurent and Pierre to comment as well. Maybe the
material is covered in the same way on another draft, and we could point
to that? (On a plane right now, can't check). If not, I would not want
to delete nor shorten it.
Made all the changes in draft-ietf-anima-reference-model.xml on github,
and created the corresponding txt file. I'm not going to submit a new
version quite yet, more comments are likely to come :-)
Co-authors: Please review and double-check. Let me know if you disagree
with any change.
See: https://github.com/mbehring/ANIMA-Reference-Model
files draft-ietf-anima-reference-model.txt and .xml.
Diff attached.
Joel: Thanks for the detailed review! It made the document better!
Michael
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
