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


_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to