Subject: [Anima] Genart last call review of draft-ietf-anima-reference-model-06

From: Joel Halpern <[email-masked]>
Date: Thu, 09 Aug 2018 18:00:39 -0700

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?

    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.

    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.

    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.)

    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.

    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.

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?

   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)?

    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.)

    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.

    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.)

    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.

    Personal opinion: Section 8 on coordination is too hypothetical to be
    useful to a reader of this document.  I think it is better removed.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Aug 2018 07:10:18 +0200

Thanks a lot, Joel

MichaelB has the editor pen, so just some quick
thoughts as co-author/chair inline.

>     list of services of the ANI in Figure 2 of section 3.1?

4.1 is explaining it. In the ACP document its called the Node-ID.

>     the term adjacency needs to be better explained in this section.  The first

Imho, the reference model text is correct. Just like in the non-autonomic
input (third bullet item), this vendor-redirect/cloud-registrar would
lead to an automatically set up remote ACP peer thats enterred into the
adjacency table. 

>     a more general form of adjacency.  As written, I think it will confuse

Hmm.. ACP is an overlay network that tries to match the underlay when
it can (link-local-adjacencies) and that uses remote adjacencies when
it needs to go over non-autonomic parts of the network.

Not quite sure what text to most easily add to make this any clearer..
Any suggestions ?

>     understanding this specification.

802.1AR as already referenced by ACP

>     may be low power devices, I think we need to be clear about what we are

Both options are architecturally valid and the reference model
does not take sides, even though we would expect that LDevID is
persistent in most cases.

I don't think low-power is the criteria for not to have a persistent LDevID,
almost every tiny IoT device i've seen has some available flash cells.

The security model of nodes without writable persistent storage comes
to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash
only, power-cycle recreates known "good" state on device).

>     in place.  That clearly requires configuring some security properties. 

I had same comment on ACP. I was going to fix it in ACP by saying
"does not need to configure security on any (ANI/ACP) nodes other
than Registrars and other PKI components (CA, CRL-DP,...).

Network can have 10,000 nodes and maybe just 2 registrar/CAs..

>     this a real requirement?  If so, it appears to be unmeetable.

chair hat on:
There can not be a draft covering this yet, because the current
ANIMA charter didn't allow us to do this. We've got individual drafts
lined up for this topic, we just need to get through the rechartering,
we have started the discuss with our AD and wanted to then bring this to
the WG.

Cheers
    Toerless

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 10 Aug 2018 10:12:37 -0400

I await Michael's comments.  A few in line responses (marked <jmh></jmh> 
where I think I may have been misunderstood.  I have trimmed the rest. 
As noted in the elided text, these are all concerned with clarity.

Yours,
Joel

On 8/10/18 1:10 AM, Toerless Eckert wrote:
...
>> Review result: Ready with Issues
...
> 4.1 is explaining it. In the ACP document its called the Node-ID.

<jmh>I saw 4.1.  If naming is intended to be a service provided by the 
ACP, then figure 2 and the text in section 3.1 apparently should include 
it. </jmh>

> lead to an automatically set up remote ACP peer thats enterred into the
<jmh>I can't find anything in the bootstrap document redirect section 
that suggests the behavior you indicate.</jmh>

> Not quite sure what text to most easily add to make this any clearer..
<jmh>The text mixes both uses of adjacency without distinction.  One 
could seaprate the usage.  One could add explanatory text.  Something to 
clarify the situation. </jmH>

> 802.1AR as already referenced by ACP
<jmh>My only concern is that it appears to need to be a normative 
reference here, as it seems to be needed for understanding this 
document. </jmh>

> only, power-cycle recreates known "good" state on device).

<jmh>The text as written implicitly requires persistent storage.  If the 
intention is to allow both models (as I would hope) please tune the text 
in section 3.3.2.

> we have started the discuss with our AD and wanted to then bring this to
<jmh>How can this informational documents say "ASA must ..." if there is 
no definition of what they must do.  If the WG has not addressed this 
topic, then reword this.  Maybe "It is expected that wide deployment in 
the future will need ..." </jmh>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Aug 2018 18:12:28 +0200

On Fri, Aug 10, 2018 at 10:12:37AM -0400, Joel M. Halpern wrote:
> <jmh>I can't find anything in the bootstrap document redirect section that
> suggests the behavior you indicate.</jmh>

Thats true, the BRSKI documents defines key cryptographic aspects
of a cloud registrar and there are a lot of options for a full solution,
and the conclusion was to do these things as followup work from BRSKI / ACP.

> <jmh>The text mixes both uses of adjacency without distinction.  One could
> seaprate the usage.  One could add explanatory text.  Something to clarify
> the situation. </jmH>

Hmm.. it does clearly distinguish the three cases through bullet
points, each one describing one of the three cases. Maybe i'm
just confused what you think is missing and Michael immediately sees it.

> <jmh>My only concern is that it appears to need to be a normative reference
> here, as it seems to be needed for understanding this document. </jmh>

I don't think its necessary to read 802.1AR to understand
the security reason why its used. BRSKI does that explanation,
and BRSKI is already normative. Personally, i dislike to have "pay-to-read"
documents as normative references, as much as i do appreciate
every SDOs need to finance itself.

> intention is to allow both models (as I would hope) please tune the text in
> section 3.3.2.

Maybe a sentence at the end:

On devices without persistent storage for the LDevID, a powercycle
should behave like a factory reset.

> <jmh>How can this informational documents say "ASA must ..." if there is no
> definition of what they must do.  If the WG has not addressed this topic,
> then reword this.  Maybe "It is expected that wide deployment in the future
> will need ..." </jmh>

I think 6.1 is just missing the (*).

Cheers
   Toerless

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 10 Aug 2018 12:16:53 -0400

At this point I think we understand each other's points, and I will wait 
for Michael to comment as pen-holder.
Thank you for the prompt response and discussion.
Yours,
Joel

PS: While I sympathize with your reaction to paying for standards from 
other SDOs, that is not what determines whether we reference them, or 
whether those references are normative.  No mater how much we wish 
otherwise :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Aug 2018 08:24:35 +1200

(CCs trimmed, since I doubt that [email-masked] cares to see the
details...)

> I think 6.1 is just missing the (*).

I hadn't thought of draft-carpenter-anima-asa-guidelines ever
going to the standards track. In any case we'd need a lot more
implementation experience before we could consider that. So IMHO
we should simply wordsmith section 6.2 to avoid any hint of a
normative requirement.

>     useful to a reader of this document.  I think it is better removed.

It's definitely a future work item, but as a minimum I think we
should state the problem, so I would suggest editing it down
rather than deleting it.

   Brian

---

From: "Michael H. Behringer" <[email-masked]>
Date: Sat, 11 Aug 2018 16:36:05 +0200

Thanks Joel for the thorough review! Sorry for the delayed response, I 
was mostly offline on business travel. As Brian, I also took 
[email-masked] off the cc, please let me know if this is inappropriate, 
in which case I repost with that list on.

Inline...

>      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.

>      a more general form of adjacency.  As written, I think it will confuse
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! :-)

>      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?
>      may be low power devices, I think we need to be clear about what we are
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>

>      in place.  That clearly requires configuring some security properties.

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>

>      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?

>     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?

>     a forward reference to 6.3.1.2 (which then has the necessary normative
Done.
>      the definition (which I think is section 5.2.)
Done.
>      added constraint is that it is not currently a member of an ACP.  The text
Done.
>      capabilities, and negotiate them.  We don't need the sentence as grounding
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)

>      find.  Presumably, PCIM should be an actual reference to the relevant RFC.
Removed SUPA, and left PCIM.
>      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

---

From: Joel Halpern Direct <[email-masked]>
Date: Sat, 11 Aug 2018 11:31:03 -0400

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 [email-masked], 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.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Aug 2018 10:36:09 -0400

Joel Halpern <[email-masked]> wrote:
    >     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.)

*) Constrained devices are not, in general, in scope for the WG
*) Regardless, the LDevID needs to be persisted, and I agree we should say that.

    > 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.

The administrator has to have a PKI.  We considered making the PKI
auto-configuring, but we backed out of that as a hard requirement.
I agree that this text need to be clarified.

    >     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.

Agreed.

    >     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.)

I think that the intent is to say that the ASA will have a model of itself.
I think that it would be better to say that.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Aug 2018 11:14:30 -0400

Thank you Michael.
Seems that we are good.
Yours,
Joel

On 8/17/18 10:36 AM, Michael Richardson wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>