Re: [Anima] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24
My apologies for the delay in responding to these comments. The changes seem to nicely address all of my comments. I hope that I will recall this well enough to avoid introducing triple-jeopardy by accident. (Having said that, it appears that my pushing on some of these issues a second time contributed to your finding good resolutions of the issues.) On the 7.2 comments, my primary comment was a mistake on my part. The only configuration required is the same configuration that is required for ACP nodes, namely turning on ACP. (Which may or may not be a default setting, but is clearly a configurable behavior.) On the comment about a corner case, I was looking for text saying roughly "An L2 node that supports ACP and is enabled to participate SHOULD do so on all its L2 interfaces. I grant this is not a big deal. My concern is if the L2 link selection is a partial / proper subset of the intended L3 adjacencies, problems could easily result due to traffic not arriving at all desired places. Thank you, Joel On 6/23/2020 10:35 PM, Toerless Eckert wrote: Thanks a lot, Joel Personal diff with just the fixes for you, otherwise feel free to compare -25 against -25, it has more fixes for Russ Housley and IPsec proto detail enhancements/fixes. http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/0caa400fd1c554ece49fddc7dabe8140195aa5bf/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/ae9e6cd856ab2706e8b38cc2552f2e77f6b676a5/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt Cheers toerless On Thu, Apr 09, 2020 at 07:16:16PM -0700, Joel Halpern via Datatracker wrote: Reviewer: Joel Halpern Review result: Not Ready Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ???http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-anima-autonomic-control-plane-24.txt Reviewer: Joel Halpern Review Date: 9-April-2020 IETF LC End Date: N/A Intended Status: Proposed Standard Summary: I have two major concern about this document that I think should be resolved before publication. The are also a number of minor items that warrant attention. Comments: While quite long, the draft is significantly improved from earlier versions. It does provide significant explanation of its design choices, which is helpful and appreciated. Sometimes this seems to end up more as marketing or promotion instead of explanation, but this is mostly harmless. Any pointers to specific text that sounds to be too marketing wise always welcome. Happy to review that. I thought i had eliminated all the ones... i did see myself. In particular, I would like to thank the authors and editors for the addition of section 9.3 and its careful discussion of the many issues there. Thank you. Major Issues: Section 6.10.3.1 on the use of Zone-IDs seems, from the material in A.10.1, to be dependent upon either configuration (which ACP is supposed to avoid) or completely unspecified magic. Having an addressing and routing scheme standardized that is impossible to use seems at variance with appropriate practice. It would be fine to say that provision is made for non-zero Zone-IDs in the hope that future work can find ways to scale further using this. But pretending it is well-defined, but not actually defining it, seems unacceptable. You brought up this issue in your -13 review and we had a longer thread about it which ended in i think this statement of yours: | <8d2d0b06-0982-53a3-0ce0-38a465f58...@joelhalpern.com> | My perspective is that I would have preferred to see the system designed such | that when Zones are needed, they can be added in a way that does not assume | system-wide knowledge of the layout choices. | | I think you could have achieved that. I understand that the working group | didn't do that. And beause it is the WG decision, I can live with it. I wish | it were better. No protection against double jeopardy in IETF ? Maybe its a good thing except for expediency of completion of the draft, because i had to rethink the issue again, and while it took a while i hope the result is especially good to help with initial ACP adoption challenges: The included
Re: [Anima] GRASP ALL_GRASP_NEIGHBORS
LAGs can balance IPSec because the SPI is cafefully placed in the same location as the UDP / TCP port numbers, so if the LAG recognizes the protocol type (which most do), it can use the SPI just teh way it uses the port numbers. Yes, it is a hack. It is an OLD hack. Yours, Joel On 4/27/2020 10:54 PM, Michael Richardson wrote: Joel M. Halpern wrote: > I suspect that for most GRASP purposes, even if there is a layer 2 network > between the parties, we are not much worried about how LAG handles GRASP > packets? If we care about that, then the source port should be randomized > between flows, and stable for sequences of related messages. The idea being that the different 5-tuples would wind up on different links of the LAG, correct? Brian E Carpenter wrote: > I think we don't care, because GRASP traffic density should be quite > modest so load balancing isn't really an issue. In response to Michael, > I don't think the source port matters at all for M_FLOOD messages. My > code uses the o/s default, but it has no significance to the > recipient. I agree with Brian: the DULL message is basically just a probe sent every few seconds. The bulk traffic would run over IPsec, so there will be an ESP SPI#. How would a LAG flow balancer deal with that? I don't think it would balance at all unless two SAs were negotiated. I think that the flow header could also be tweaked in some kind of round robin fashion. But, if it's a MC-LAG, then the ACP really wants to see both chassis seperately. So it occurs to me that we could hack LACP rather than LLDP :-) It appears that it uses a specific multicast destination. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] GRASP ALL_GRASP_NEIGHBORS
I suspect that for most GRASP purposes, even if there is a layer 2
network between the parties, we are not much worried about how LAG
handles GRASP packets? If we care about that, then the source port
should be randomized between flows, and stable for sequences of related
messages.
Yours,
Joel
On 4/27/2020 6:14 PM, Michael Richardson wrote:
Brian E Carpenter wrote:
> No, that normally gets resolved when they actually start editing, but
> yes of course it's on my checklist.
> I'm quite sure the early aassignments were announced on the list, but
> when I forget what values were pre-assigned I just go and look at my
> code:
I thought that early allocations were supposed to go into the document so
they don't get assigned twice by mistake.
> ALL_GRASP_NEIGHBORS_6 = ipaddress.IPv6Address('ff02::13') # LL
multicast
> ALL_GRASP_NEIGHBORS_4 = ipaddress.IPv4Address('224.0.0.119') # LL
multicast
> GRASP_LISTEN_PORT = 7017 # IANA port number
Thank you.
Is there any reason why the source port (for DULL, and normal) can't be port
7017 as well?
It clearly could be any port...
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
All three of those sound like improvements. WHichever one you and the working group pick would clearly help. Thank you, Joel On 7/17/2019 5:13 PM, Michael Richardson wrote: Joel M. Halpern wrote: > Thank you Michael. I saw the proposed change in section 9. I wonder > if that is hiding the MUST, since the mechanisms are in section 7... > Having said that, I can live with it as you have proposed. I take your point. Options I see are: 1) swap the sections so section 9 (applicability) comes before 7 (reduced security) 2) mention the ACP applicability in section 7. 3) move the 7.2 section to section 9. The intention with section 7 is to provide a palette of things, and let their use be dictated by how the protocol is applied. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
With the mandates that Michael proposed adding, I can live with advancing the document. Yours, Joel On 7/16/2019 4:31 PM, Brian E Carpenter wrote: Up-levelling the topic a little bit: It seems to me that from the amount of interest and discussion, BRSKI is going to be quite important (or a resounding failure, in which case this is all beside the point). Assuming it's a success, there will inevitably be updates and enhancements. So, I'd prefer that we don't try to solve all problems now. I'd rather get the first version to Proposed Standard next week... Regards Brian Carpenter On 17-Jul-19 01:57, Joel M. Halpern wrote: I can't tell from this whether you agree that it is reasonable to put in some mechanism to address this issue? Yours, Joel On 7/16/2019 9:40 AM, Eliot Lear wrote: Hi Joel, On 16 Jul 2019, at 14:59, Joel Halpern Direct wrote: I am having trouble connecting your reply with my request. Let's take the direct issue first, and then the analogy. I had suggested a specific enhancement to device behavior. The response was "but that removes the theft protection." It is that form of theft protection that I am objecting to. As far as I can tell, the mechanism I suggested does not break zero touch. It allows someone who controls their network, and who physically controls a new device, to put that new device in their network without asking anyone's permission. It does not permit someone with a device, but not network control, from adding that device to the network. It does not permit someone with control of the network, but not physical access to the device, to achieve anything special. So it seems compatible with the goals. My apologies I took your statement as something more general than you intended. With respect to this from earlier: I have assumed that what we needed is the ability for a buyer, who has physical possession of the device, and possibly some simple (non cryptographic) credentials provided by the seller to force the device to reset what it thinks it is part of, and to emit in some accessible form the information the buyer needs to be able to make this device part of his network, using his authentication servers, etc. That was indeed what we discussed. We just got into means a bit more than perhaps necessary. I’ll point out that it’s always going to be a manufacturer call on how best to do this; and how to transport credentials, and how to keep them safe, even. In terms of the analogy, I would have problem with IEtF defining a new protocol that added significant risk to the buyer when they buy from new vendors. And existing vendors do go out of businesses. And vendors do end-of-life products. (You can't get a new key to your car because the vendor has stopped supporting that model???) I wouldn’t implement a 1:1 mapping products->MASA server function. That seems excessive. And rare is the case when a vendor EOLs a product and then cripples it through an update mechanism. The only issue here is whether a database entry would stay around. Now it may be that the particular approach I suggested won't work. But it seems to me that there needs to be a way for folks to keep using, and to keep re-selling, devices without the support of the vendor. That usage may not get all the zero-touch advantages that supported re-sale would get. But it has to work. And putting the onus for that on the original vendor does NOT seem an effective solution. I think you mean, “requiring the vendor to stay around for ever doesn’t seem like an effective solution.” Again, I don’t want to overgeneralize. Eliot ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Thank you Michael. I saw the proposed change in section 9. I wonder if that is hiding the MUST, since the mechanisms are in section 7... Having said that, I can live with it as you have proposed. Yours, Joel On 7/16/2019 3:47 PM, Michael Richardson wrote: Joel Halpern Direct wrote: > It allows someone who > controls their network, and who physically controls a new device, to > put that new device in their network without asking anyone's > permission. Right, get your "blue cable" out, connect it to the serial console, bring up minicom, and tell the device to enroll. Verify the registrar's certificate when prompted, perhaps. You can still use GRASP to find the Registrar, and all the rest of the ACP mechanism or not. That's been in section 7.2, but the complaint was that it was not normative. So, we have added in section 9, for the ACP use case, that implementing something is a MUST. I don't think it will work for lightbulbs, but whomever writes that Applicability Statement will have to cope with that. (it will be me: I have a document in 6tisch, which is that document. I would appreciate your thoughts on what might be acceptable there) BTW: A number of router manufacturers have BRSKI-like mechanisms already, but they only really work when you drink all their koolaid, and build your network exclusively with their equipment. At one ISP that I consult for, they wound up turning the super-duper auto-join management system off because it ate all of a very high end VM platform, and they just couldn't afford that at the time... Maybe cross-vendor mechanisms will result in some competition and some better products. > Now it may be that the particular approach I suggested won't work. But > it seems to me that there needs to be a way for folks to keep using, > and to keep re-selling, devices without the support of the vendor. > That usage may not get all the zero-touch advantages that supported > re-sale would get. But it has to work. And putting the onus for that > on the original vendor does NOT seem an effective solution. As long as vendors support blue cables, and are willing to provide firmware updates, I don't see any change. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
I can't tell from this whether you agree that it is reasonable to put in some mechanism to address this issue? Yours, Joel On 7/16/2019 9:40 AM, Eliot Lear wrote: Hi Joel, On 16 Jul 2019, at 14:59, Joel Halpern Direct wrote: I am having trouble connecting your reply with my request. Let's take the direct issue first, and then the analogy. I had suggested a specific enhancement to device behavior. The response was "but that removes the theft protection." It is that form of theft protection that I am objecting to. As far as I can tell, the mechanism I suggested does not break zero touch. It allows someone who controls their network, and who physically controls a new device, to put that new device in their network without asking anyone's permission. It does not permit someone with a device, but not network control, from adding that device to the network. It does not permit someone with control of the network, but not physical access to the device, to achieve anything special. So it seems compatible with the goals. My apologies I took your statement as something more general than you intended. With respect to this from earlier: I have assumed that what we needed is the ability for a buyer, who has physical possession of the device, and possibly some simple (non cryptographic) credentials provided by the seller to force the device to reset what it thinks it is part of, and to emit in some accessible form the information the buyer needs to be able to make this device part of his network, using his authentication servers, etc. That was indeed what we discussed. We just got into means a bit more than perhaps necessary. I’ll point out that it’s always going to be a manufacturer call on how best to do this; and how to transport credentials, and how to keep them safe, even. In terms of the analogy, I would have problem with IEtF defining a new protocol that added significant risk to the buyer when they buy from new vendors. And existing vendors do go out of businesses. And vendors do end-of-life products. (You can't get a new key to your car because the vendor has stopped supporting that model???) I wouldn’t implement a 1:1 mapping products->MASA server function. That seems excessive. And rare is the case when a vendor EOLs a product and then cripples it through an update mechanism. The only issue here is whether a database entry would stay around. Now it may be that the particular approach I suggested won't work. But it seems to me that there needs to be a way for folks to keep using, and to keep re-selling, devices without the support of the vendor. That usage may not get all the zero-touch advantages that supported re-sale would get. But it has to work. And putting the onus for that on the original vendor does NOT seem an effective solution. I think you mean, “requiring the vendor to stay around for ever doesn’t seem like an effective solution.” Again, I don’t want to overgeneralize. Eliot ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Adding such scope text, along with the mechanism to get the needed credentials, would be fine with me. Joel On 7/15/2019 6:28 PM, Brian E Carpenter wrote: Joel, I'd be happy with that as long as there is a scope statement that makes it clear to the reader. Regards Brian On 16-Jul-19 09:42, Joel M. Halpern wrote: I would probably go a step further than Adam. Protecting the device so a thief can not use it in the thiefs' own network seems to me to be something that we should not be trying to achieve. An active non-goal. It is not our problem. And trying to achieve it has the implications that lead to this whole discussion about the original manufacturer controlling who can resell / re-buy the device. While manufacturers may like that, it does not seem to be something we should get involved in. At all. Yours, Joel On 7/15/2019 5:10 PM, Adam Roach wrote: On 7/15/19 3:38 PM, Brian E Carpenter wrote: On 15-Jul-19 16:45, Joel M. Halpern wrote: I presume I am missing something basic. I have tried to follow this discussion, as it seems to be about a critical aspect of whether the BRSKI work is acceptable. I have assumed that what we needed is the ability for a buyer, who has physical possession of the device, and possibly some simple (non cryptographic) credentials provided by the seller to force the device to reset what it thinks it is part of, and to emit in some accessible form the information the buyer needs to be able to make this device part of his network, using his authentication servers, etc. Yes, but *not* a solution that works if the device is stolen. I'm actually a little ambivalent with respect to this use case. For the kind of devices that the document purports to be targeting, I would imagine that theft is in the range of parts-per-thousand (or lower) as compared to things like post-bankruptcy liquidation. If you can fix the first without ruining the second, great. /a ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
I would probably go a step further than Adam. Protecting the device so a thief can not use it in the thiefs' own network seems to me to be something that we should not be trying to achieve. An active non-goal. It is not our problem. And trying to achieve it has the implications that lead to this whole discussion about the original manufacturer controlling who can resell / re-buy the device. While manufacturers may like that, it does not seem to be something we should get involved in. At all. Yours, Joel On 7/15/2019 5:10 PM, Adam Roach wrote: On 7/15/19 3:38 PM, Brian E Carpenter wrote: On 15-Jul-19 16:45, Joel M. Halpern wrote: I presume I am missing something basic. I have tried to follow this discussion, as it seems to be about a critical aspect of whether the BRSKI work is acceptable. I have assumed that what we needed is the ability for a buyer, who has physical possession of the device, and possibly some simple (non cryptographic) credentials provided by the seller to force the device to reset what it thinks it is part of, and to emit in some accessible form the information the buyer needs to be able to make this device part of his network, using his authentication servers, etc. Yes, but *not* a solution that works if the device is stolen. I'm actually a little ambivalent with respect to this use case. For the kind of devices that the document purports to be targeting, I would imagine that theft is in the range of parts-per-thousand (or lower) as compared to things like post-bankruptcy liquidation. If you can fix the first without ruining the second, great. /a ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
I presume I am missing something basic. I have tried to follow this discussion, as it seems to be about a critical aspect of whether the BRSKI work is acceptable. I have assumed that what we needed is the ability for a buyer, who has physical possession of the device, and possibly some simple (non cryptographic) credentials provided by the seller to force the device to reset what it thinks it is part of, and to emit in some accessible form the information the buyer needs to be able to make this device part of his network, using his authentication servers, etc. Have I got the wrong end of the stick? Joel On 7/14/2019 5:33 PM, Michael Richardson wrote: Eliot Lear wrote: > Whether such a voucher would be pinned is something we do not have to > specify, with the risks of it not being pinned being born by the owner. I beg to differ! I think that the security properties are vastly different. It's why we decided when creating RFC8366 not to do bearer tokens. We simply didn't think we were competent enough to specify it tightly enough to not become a security disaster. An unpinned voucher is some kind of bearer token, and if disclosed has significant operational risk. As such, keeping it around/online is a serious issue. A voucher pinned to the public part of a keypair whose private key is kept offline (to be turned over to a new owner) is different because there are potentially far fewer things to keep private. Worse case, it's perhaps the same, I would agree. The bigger problem is that I don't see a way to define such an artifact in a timely fashion, nor do I know which WG we'd do it in. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
Off-list: It sounds from you rnote like either: 1) Anima admission process is seriously underspecified in a way that affects itneroperability, or 2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and advanced (if desired) by some other working group. I doubt either is your intention. And statements such as Eliot's ill-formed comment that no one would do that do not help the case for the Anima WG having thought this through. Yours, Joel On 10/2/18 3:46 PM, Brian E Carpenter wrote: On 2018-10-03 08:00, Michael Richardson wrote: lear> I think we've lost sight of what we're talking about. We're talking lear> about a completely automated method for a local trust anchor to be lear> installed on a device, and a kick to EST for the device to receive a lear> local credential. For that to happen there needs to be a trusted lear> introduction, and the device manufacturer or its agent is in the best lear> position to do that. Randy Bush wrote: > no. the owner's trust controller is. Cool. It's a relief to know that we've missed something obvious. Could you please explain things more? We call the owner's trust controller the "Registrar", or sometimes the Join-Registrar/Coordinator. I don't mind calling it a trust controller, but maybe your term has a different meaning. There's a point that close followers of Anima may know and that others don't. There is a topic intentionally missed out of the BRSKI document, which is how the registrar decides whether a particular device, let's say device X12345, is allowed to join the secure domain in question. This point is skated over in the draft; in fact there is a text glitch in section 5.2 where it should be stated, already known to the authors. (Sorry, but we didn't find that text glitch soon enough to fix it before the IETF Last Call.) The actual authorization mechanism - "X12345 is allowed to join" - is not part of BRSKI. It is, as Randy rightly implies, not the business of the manufacturer. The MASA is used only to verify that X12345 is in fact X12345. It's part of the trust model, not the authorization model. If I had my wishes, the MASA would be optional, with a local voucher store in the registrar as the alternative. But that wasn't the WG consensus. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
That answer seems to imply that if the MASA is down before I try to transfer my device, and if the MASA is still down when the recipient tries to get my device working, it won't work. Which seems to mean that once a MASA goes down permanently, any new can not get a device reliant on that MASA to work. Seems a pretty severe limitation. Yours, Joel On 9/30/18 3:58 PM, Brian E Carpenter wrote: On 2018-10-01 07:52, Randy Bush wrote: christian, a stunning review as usual. but i have two questions which you kind of finessed. they are simple binary, i.e. yes/no, questions that the end user, to whom the IETF is ultimately responsible, really cares about. if the manufacturer's servers go down, either permanently or even for a day, can i give/sell the device i have purchased to a third, well fourth i guess, party, at my whim and seamlessly unencumbered? There are two conditions for it to work as I understand: 1) The device ID is added to the list of devices acceptable to the registrar in its new network. AND 2) That registrar is able to contact the MASA. Alternatively - see the previous point. If you had previously obtained a voucher in advance, you could include it with the device. Just as you might write the hard disk password on a yellow sticky when selling a laptop in a garage sale. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06
Thank you Michael. Seems that we are good. Yours, Joel On 8/17/18 10:36 AM, Michael Richardson wrote: Joel Halpern 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. > 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. 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 [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06
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 :-) On 8/10/18 12:12 PM, Toerless Eckert wrote: On Fri, Aug 10, 2018 at 10:12:37AM -0400, Joel M. Halpern wrote: 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. I can't find anything in the bootstrap document redirect section that suggests the behavior you indicate. 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. 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 ? The text mixes both uses of adjacency without distinction. One could seaprate the usage. One could add explanatory text. Something to clarify the situation. 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. 802.1AR as already referenced by ACP 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. 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. 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). 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. Maybe a sentence at the end: On devices without persistent storage for the LDevID, a powercycle should behave like a factory reset. 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. 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 ..." I think 6.1 is just missing the (*). Cheers Toerless ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06
I await Michael's comments. A few in line responses (marked 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: On Thu, Aug 09, 2018 at 06:00:39PM -0700, Joel Halpern wrote: Reviewer: Joel Halpern Review result: Ready with Issues 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? 4.1 is explaining it. In the ACP document its called the Node-ID. 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. 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 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. I can't find anything in the bootstrap document redirect section that suggests the behavior you indicate. 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. 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 ? The text mixes both uses of adjacency without distinction. One could seaprate the usage. One could add explanatory text. Something to clarify the situation. 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. 802.1AR as already referenced by ACP 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. 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.) 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). 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. 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 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.. 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. 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
Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13
Thank you. Those fixes make sense. You might want to talk to a DNS expert about what the right terminology is for what youa re trying to achieve with the rsub content. I think I understand it, and I think it is reasonable. And I am insufficiently expert to tell what the right formalism is for it (thinks have evolved since 1034.) Net: good enough for me. Yours, Joel On 6/8/18 7:04 PM, Toerless Eckert wrote: Thanks, Joel Replies Inline Changes for feedback from Mirja, Kumar and Joel committed to -16, didn't create separate diff for individual reviewers as diff is not large. (Just ignore whole section 11 moved to appendix in diff.) https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-15.txt=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt Cheers Toerless On Thu, Jun 07, 2018 at 05:09:37PM -0400, Joel M. Halpern wrote: Thank you for all your work on this. While I still find the presence of the address allocation mechanism strange to find in this document, I can live with it. So with this complaint done, I will shut up about it already. Thanks. Lets take it offline. I am still interested to understand that point, especially after the text i added in the hope to clear this concern. Answers inline. Thanks Toerless Aside from some items noted below, this seems to be in good shape. Moderate: Section 10.3.4 has a helpful discussion of some of the complexities of determining where to auto-enable the ACP. I am a bit surprised not to see some discussion of which VLANs to enable for ACP in an Ethernet environment. Thats a topic better to be discussed in followup work. Cisco IOS ACP implementation does support automatic VLAN discovery & selection. Lot of experience/insight from that. Trust me, it would be scope creep for the ACP document itself. For WDM< since wavelength usage is configured, I presume that ACP would never try to auto-enable a frequency band? Right. Given the experience with VLANs, the clean cut we could make for this basic ACP specification is to logically sit on top of IPv6 subnet interfaces, ignore all L2/L1 complexities and live with the dependency against IPv6 being able to bring up link-local-scope reachability to neighbors. [ And then write followup docs if/when we ever get this first doc out as an RFC ;-) ] The way i would imagine WDM is a bit more like ethernet switches in section 7 though: You'd want to get ACP connectivity across your optical equipment and also be able to reach through the ACP your optical equipment, but that would not use special colors, but more likely should be added to / leverage the existing in-band management channels of the optical equipment. Long discussion. Let me rather stop. Minor comments: In section 6.1.1 the text and the ABNF says that an rsub is a full domain (using the same domain-name construct as the "domain" which is an FQDN. However, the example shows a partial domain string which is concatenated with the "domain" to produce an FQDN. And the syntqx of "routing-subdomain" shows that concatenation. This suggests that the text needs to be clear as to what the syntactic content of the rsub field is. Hmm... RFC1034 does not even mention the term "fully qualified (domain name)" / FQDN, You seem to read RFC1034 3.5 to mean that all domain are FQDN, but that is not clear to me. In the RR examples of RFC1034, FQDNs are identified by ending with a ".", which AFAIK is the standard for FQDN,but the 3.5 syntax doesn't even allow you to create such an FQDN, so i was thinking that 3.5 "domain" do not have to be FQDNs, and therefore i am assuming that is is also perfectly legal to use a syntax of domain3 = domain2 . domain1, as in routing-subdomain = rsub . domain-domain-name. Might it be better not to define it as a "domain-name" but to define it as FFS, with a caveat that whatever usage is later defined needs to be suitable for combining with the "domain" for generating the hash for the ULA Global ID? Well, it does have to be some RFC822-local-part-FFS, but i think its a lot better if its constrained to the domain name syntax, because it is quite normal operations to have for every actual routing subdomain in the network also some associated domain name, and that is what "routing-subdomain" is. So if i build a parser for configuring my segmented routing with the ACP, its a lot more logical to allow only longer domain names for routing-subdomain that all have the same parent domain (domain). Just to be clear, as written the text seems to end up with where is from RFC 1034. Right. See above. I tried to figure out how to unconfuse this. I changed "domain" to "acp-domain-name", so that its not confused with RFC1034 "domain",
Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13
Thank you for all your work on this. While I still find the presence of the address allocation mechanism strange to find in this document, I can live with it. So with this complaint done, I will shut up about it already. Aside from some items noted below, this seems to be in good shape. Moderate: Section 10.3.4 has a helpful discussion of some of the complexities of determining where to auto-enable the ACP. I am a bit surprised not to see some discussion of which VLANs to enable for ACP in an Ethernet environment. For WDM< since wavelength usage is configured, I presume that ACP would never try to auto-enable a frequency band? Minor comments: In section 6.1.1 the text and the ABNF says that an rsub is a full domain (using the same domain-name construct as the "domain" which is an FQDN. However, the example shows a partial domain string which is concatenated with the "domain" to produce an FQDN. And the syntqx of "routing-subdomain" shows that concatenation. This suggests that the text needs to be clear as to what the syntactic content of the rsub field is. Might it be better not to define it as a "domain-name" but to define it as FFS, with a caveat that whatever usage is later defined needs to be suitable for combining with the "domain" for generating the hash for the ULA Global ID? (Just to be clear, as written the text seems to end up with where is from RFC 1034. Section 6.1.2 bullet one states that "The peer certificate is valid as proven by the security association protocol exchange." I may be overstepping my knowledge, but I think there are two different things. First is the certificate validity, which is an internal property of the certificate. The second is the certficate applicability which may be informed by the protocol exchange. Related to that, please put in a reference to which protocol exchange you mean? Either there is a document inconsistency, or there is a typo in the first paragraph of section 6.10.7.3, in that the address prefix length for the zone address sub-scheme is /127, not /126. Yours, Joel ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13
(Sorry about the excess caps. Did not intentd to shout.) From some off-line disucssions, I understand that the actual address allocation is tied to the registration process. The registration process is not described in this document. As far as I can tell, the ACP does not depend upon the address allocation strategy. The address allocation strategy does require the ACP. And it requires and is closely coupled to the registration process. If that is true, the address allocation seems to be better described with the registration process. Which I presume is in the BRSKI document. All I would put in here is the basic ULA allocation (hash based generation) mechanism. Yours, Joel On 5/14/18 10:58 PM, Toerless Eckert wrote: On Mon, May 14, 2018 at 08:49:56AM -0400, jmh.direct wrote: I think the I understand what you describe. As far as I can tell, the ACP DOES NOT AND SHOYLD NOT MANDATE the address assignment mechanism. But it is the address assignment mechanism that drives the address allocation. But that exactly is the conclusion of the multi-year ACP work in ANIMA WG. The ACP of an unconfigured, but only certificate enrolled device needs to be able to bring up routing and addressing for the ACP autonomically, aka: without any other dependencies. This ACP draft as it stands only depends on BRSKI and some unmodified CA to be implemented and deployed. There is no NOC with any address management functions required. At minimum, addressing is solely done from th registrar, and you can have many registrars in a network and there is no chance for inconsistent address configuration. Please propose any other solution that you are thinking of in enough detail to discuss it, and i think we can show it has more, and often future/undefined problems to be resolved. I would expect to find the address structure for autonomic addressed in the same document as the mechanisms for autonomic address assignment. The ANIMA autonomic address asignment draft is relying on the ACP to be operational end-to-end to signal amongst its components via ACP GRASP the address/prefix assignments. It can by definition not be used to bring up routing and addressing of the ACP itself. It likely also required more centralized functionality. For what it tries to do, it is elegant, flexible and all that because it does not have to bother about bootstrap addressing and routing for itself as the ACP has to do. https://en.wikipedia.org/wiki/Bootstrapping#/media/File:Zentralbibliothek_Solothurn_-_M%C3%BCnchhausen_zieht_sich_am_Zopf_aus_dem_Sumpf_-_a0400.tif BRSKI+ACP are doing what poor Muenchhausen is trying to do in what i think is a quite lightweight, very secure, scalable and for the job at hand (ugly) quite elegant way. That is, why the routing scheme seemed confusing after the address allocation scheme. If you can be more explicit about what you think is confusing, i am happy to make any confusing text better. Note that routing protocol/profile and addressing scheme are all subject to future enhancements easily. But in the design of anima, we would like to have operator defined address policy to be part of intent, and that would not only requir a lot more future work, it would also make addressing assigned this way less reliable and would not allow to use addresses managed dyanmically be used by components that are used to implement the Intent infrastructure or any future ANI components (ASA etc.) that intent or address management depends on. Cheers Toerless Yours,Joel Sent via the Samsung Galaxy S® 6, an AT 4G LTE smartphone Original message From: Toerless Eckert <t...@cs.fau.de> Date: 5/14/18 05:04 (GMT-05:00) To: "Joel M. Halpern" <j...@joelhalpern.com> Cc: rtg-...@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, i...@ietf.org, anima@ietf.org Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13 a) Will try to do better explanation of identifier nature of addresses in next commit. b) what do we loose if get rid of the choices. I kinda thought i had answered this already, but i really don't know where your concern starts... 1. We use ULA because we want to be able to bring up ACP networks without requiring a registry allocation of a prefix, and ULA is the correct private address space. And deriving ULA Global ID from hash of domain name is nice. Sounds as if you agree with this. 2. We want to be able to allocate addresses to ACP/ANI devices without any additional configuration from multiple independently running registrars. Thats why the global unique ID of the registrar is part of the address in both zone and Vlong format. Thats very fundamental to the ease of deployment of ACP/ANI nodes (i say ANI, because its really ACP+BRSKI required here to get a simple standard solution to create the cert
Re: [Anima] Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13
Comments in line. Areas of clear agreement elided. On 5/7/18 3:30 PM, Toerless Eckert wrote: Joel, Sorry for the late reply. Bufferbloat. Okay. Thank you for addressing a number of the points effectively. Let's see if we can solve the remaining items. The definition of data-plane seems to assume that all forwarding (and control?) in all nodes is structured in terms of VRFs. That seems to overly constrain implementation architecture. Using VRF to to describe the ACP functionality is a little odd, but likely defnesible. Declaring that all other functionality is in VRFs seems a step too far. Oh... rathole ;-) I spent a lot of time pondering this problem. ... In response to you bringing up the naming issue, i went through the doc and removed "VRF" where it was used for the data-plane, so as not to imply the use of VRF other than for the ACP itself. There is still some amount of VRF in the "VRF selection" section, thats really too hard to describe without VRF - would just make it too convoluted. Good enough. Thank you. It is unclear how the flexible policy defined in section 5 bullet 2 (about which nodes are ACP peer candidates) is consistent with autonomic operation. It seems that the flexibility is important, so there should be some explanation here about how this is consonant with the stated goals. I understand that the bootstrap comes from BRSKI, but I do not think that is where the policy comes from? Would rather not like to add more suggestive text, and thats at best what i could add. The default policy is the best "autonomic" behavior we know how to make work: aka: try to connect ACP to all neighbors you can discover. And we have only defined with DULL GRASP how to find subnet adjacent neighbors. The main reason to mention policy is so that there is some leeway to do more or even (sigh) less than all direct neighbors. After looking at this, I think I can live with what you already have. I think there are some issues, but let it be. If the rsub is empty, but the extensions are not empty, it looks like there will be two plus signs (following the optional acp-address) before the first extension. Is that intended as the way to indicate the absence of the rsub? Yes. Otherwise it would be ambiguous to parse. Haven't written something about this because i think readers eithrer don't care or the can figure it out easily. I think it would help to state it explicitly. (section 6.1.1) It also seems odd that the rsub (which is a domain extension) appears in the local-part of the domain information, not in the domain name. Even though for hashing purposes it is concatenated, with a period, with the domain name. If these oddities are intentional, then there ought to be explanations so the reader is not confused. The difference between domain and routing-subdomain are explained directly after the BNF: "domain" is used to indicate the ACP Domain across which all ACP nodes trust each other and are willing to build ACP channel to each other. See . "routing-subdomain" is the autonomic subdomain that is used to calculate the hash for the ULA prefix of the ACP address of the node. ... Added: "rsub" needs to be in the "local-part"; it could not syntactically be separated from "domain-name" if "domain" is just a domain name. It also makes it easier for domain name to be a valid e-mail target. Okay. It is odd, but works. I presume there is not an assumption that all ULA addressed communicating with a node which supports the ACP will be over the ACP. As I understand it, ULAs may well have other uses outside of ANIMA / the ACP. Which leads to a question about how the text in 6.1.3 "If the CDP URL uses an IPv6 ULA, the ACP node will try to reach it via the ACP." is expected to be supported? The reason is that the ACP certificate maintenance runs across the ACP so that we have a simple security model for the ACP certificate lifecycle. We do not want to have to figure out the impact of attacks against connectivity to the CDP when it runs across the data plane. After all, these are ACP certificates are also renewed via EST across the ACP. I added the following explanation sentence: Reaching the CDP across the ACP implies that the CDPs need to be reachable via the ACP, for example by running CDPs on registrars or on devices connected to the ACP via ACP connect (see ). While a useful addition, that is not what I was asking about. The text as written seems to say that simply because the RDP uses an IPv6 ULA, the node will know to use ACP for the communication. I understand why we awant the communication to use ACP. I don't understand how that is achieved. The way the text is written, it seems to imply that it is a property of IPv6 ULAs. Which I don't think is your intention. So I would like to see clarification. See also (2) at end.
Re: [Anima] Fwd: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt
Even if you want a simple mechanism, I think the bidirectionality and block numbers would be VERY good ideas. I think these two are critical. Without either resumption or retransmission, there seem to be many environments where low complexity is valuable but the system is unlikely to be able to perform the transfers. This does edge into the argument about how much size and work it would be to just use the code for an existing protocol. Yours, Joel On 9/12/17 12:56 AM, Brian E Carpenter wrote: Hi Joel, thanks for the rapid comments. More in-line: On 12/09/2017 15:17, Joel M. Halpern wrote: Given our experience with file transfers, several things seem to be called for: 1) There should be a mechanism for the sender to initiate. Several of the use cases you cite are such that the sender would better than the receiver when it is a good time to send the data. Yes, certainly. That's behind the mention that the mechanism could be turned round for upload. Maybe it would be better to call it push and pull, since ANIMA does not assume a hierarchy. 2) I realize that it does not fit the pattern, but without some sort of position indication, this seems very fragile. I think you need to come up with a way to indicate the position. It wouldn't be hard to add a block number, both for the sending side and the acknowledgements. But then it would be very tempting to also add a retransmission mechanism, and look, we've re-invented the wheel. So we just have to decide where to stop in complexity. 3) Unless we want to restrict this to very local environments, we really should have a way to resume a failed transfer at the failure point, rather than start from teh beginning. Ditto. To be honest I had to stop myself adding such mechanisms, when writing a quick prototype. > In particular, without these features, the justification for using GRASP rather than a better transfer protocol over the ANIMA infrastructure becomes very weak. Well, there we might disagree. Or at least, that is the question of scope. What do we want to assume is already installed on an autonomic node? If it's a fully-featured host or host-like device, I would expect some existing mechanism to be available. If it's a bare-bones device, maybe not. But in that case, we'd want a GRASP-based mechanism to be bare-bones too*. We'd be interested in WG opinions about this. *Just to scale it, the client side that corresponds to the example in the draft is about 110 lines of Python. Thanks Brian Yours, Joel On 9/11/17 9:41 PM, Brian E Carpenter wrote: Comments welcomed! Forwarded Message Subject: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt Date: Mon, 11 Sep 2017 18:32:28 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP) Authors : Brian Carpenter Sheng Jiang Bing Liu Filename: draft-carpenter-anima-grasp-bulk-00.txt Pages : 10 Date: 2017-09-11 Abstract: This document describes how bulk data may be transferred between Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol (GRASP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-anima-grasp-bulk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-anima-grasp-bulk-00 https://datatracker.ietf.org/doc/html/draft-carpenter-anima-grasp-bulk-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Need WG input: Alexy Melnikov's suggestion on GRASP
If, as he says, that is the best current practice then lets go for it. Joel On 5/28/17 9:38 PM, Brian E Carpenter wrote: Hi, I have started the process of going through IESG comments on the GRASP draft. Where something is editorial or obviously non-controversial, I will not ask for input. But I do need input on some things, and here is the first. Please answer quickly; no answer will be taken to mean that you don't care... Alexy wrote: uri-locator = [O_URI_LOCATOR, text] I suggest inclusion of optional transport protocol here to match other locators and to follow best practices for not encoding transport information in URIs. That would become uri-locator = [O_URI_LOCATOR, text, transport-proto, port-number] Opinions? Objections? Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] privacy in discovery
The question that occurs to me is whether the pre-ACP discovery phase needs privacy protection. The answer is not obvious, since the scope is limited (where DNS queries can go arbitrary distances across the net.) Yours, Joel On 3/11/17 2:20 PM, Brian E Carpenter wrote: On 12/03/2017 08:08, Michael Richardson wrote: I haven't read the document yet, just the abstract. I am not suggesting it, just relaying that this privacy issue seems to be something others have recognized as a concern. Do you see it as a concern inside the ACP? I would have thought not. We have intentionally punted on ASA authorization for now, but it seems to me that an authorization system for ASAs (is ASA X allowed to access objective Y?) would cover the issue. The GRASP spec has a few words starting: "Generally speaking, no personal information is expected to be involved in the signaling protocol, so there should be no direct impact on personal privacy..." Brian Subject: [dnssd] I-D Action: draft-ietf-dnssd-privacy-01.txt ... ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt
Laurent, the text in section 3 of your document is informative. I am left confused about what are the actual definitions of and relationships between an AF (Autonomic Function) and an ASA (Autonomic Service Agent)? The definition Michael pointed at and the conversation on the list seem quite different. Yours, Joel On 7/11/16 10:45 AM, Laurent Ciavaglia wrote: Hello, There is some text in draft-peloso-anima-autonomic-function-01 (https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) detailing what should be considered when installing, instantiating and operating AF/ASA. Please see sections 3+. Feedback on the text is most welcome as this will be presented at IETF96/Berlin. Best regards, Laurent. On 11/07/2016 14:55, Joel M. Halpern wrote: I believe your description, and that of others as to what we "intend", does not line up with the definition you quote. The text says that an ASA "implements an autonomic function." That seems to say that I sould expect an autonomic function to be implemented by an ASA, thus implying a 1-1 relationship. yet, your example states an AF of "bootstrapping", but the funcitonality of the ASA being a much smaller piece. Net: No, the words do not clearly state what we intend. Yours, Joel On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote: ... Also, how is the relevance for each ASA known? My proposal: Intent comes in sections; those sections are labelled with the name of the ASA / autonomic function they belong to. Also here, there are many ways to do this, it's a simple proposal which could be optimised in many ways. And is that the correct granularity of the section? Maybe the granularity should be individual objectives, or certain groups of objectives? I think this needs more discussion. On this one I agree!! We should have more discussions on that. Your point from the other mail, that we should try implementing some ASAs would help understand this better. Yes. There's been an assumption, I think, that one "autonomic function" == one ASA. We need to be clear if that is an axiom, and we need to think about how ASAs are named, and if those names need to be registered somehow. Yes, that misunderstanding keeps popping up all the time. I think RFC7575 is quite clear: Autonomic Function: A feature or function that requires no configuration and can derive all required information through self- knowledge, discovery, or Intent. Autonomic Service Agent: An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function) or whole. Example: There is the "autonomic function" "bootstrapping of new nodes". It consists of 3 different ASAs: The new_device ASA, the proxy ASA and the registrar ASA. How can we make that clearer? (I thought RFC7575 *is* clear). ... ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima -- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
