Hi, > 5. Proxy Discovery Protocol Details ... > proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address, > transport-proto, port-number ] ]
If that's a GRASP objective, it needs to include the loop-count and flags fields. Also, I thought it was officially a "Join Assistant" now... Also, if you use M_FLOOD to announce it, you MAY associate a locator directly with the flood message, so you don't need it in the value field. > 6. Registrar Discovery Protocol Details > > The registrar responds to discovery messages from the proxy (or GRASP > caches between them) as follows: (XXX changed from M_DISCOVERY) > > objective = ["AN_registrar", F_DISC, 255 ] > discovery-message = [M_NEG_SYN, session-id, initiator, objective] That's a bit confused too. I don't know quite what it's supposed to mean. I think the basic point is that the spec should focus on the objectives and the semantics of their value fields. Get that right and the use of GRASP messages will fall out immediately. We can code up a Python model during the hackathon, with a bit of luck. I already have that for the versions of the objectives in draft-carpenter-anima-ani-objectives-01. After that, figure out some example message flows. ... > ...In each case, the traffic SHOULD be proxied to the same > port at the ULA address provided. Yes, we hope it will be a ULA address in the ACP, but that isn't a protocol issue in itself. Any address should work. Regards Brian On 14/03/2017 10:52, [email protected] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Autonomic Networking Integrated Model and > Approach of the IETF. > > Title : Bootstrapping Remote Secure Key Infrastructures > (BRSKI) > Authors : Max Pritikin > Michael C. Richardson > Michael H. Behringer > Steinthor Bjarnason > Kent Watsen > Filename : draft-ietf-anima-bootstrapping-keyinfra-05.txt > Pages : 55 > Date : 2017-03-13 > > Abstract: > This document specifies automated bootstrapping of a remote secure > key infrastructure (BRSKI) using vendor installed X.509 certificate, > in combination with a vendor's authorizing service, both online the > Internet, and offline. Bootstrapping a new device can occur using a > routable address and a cloud service, or using only link-local > connectivity, or on limited/disconnected networks. Support for lower > security models, including devices with minimal identity, is > described for legacy reasons but not encouraged. Bootstrapping is > complete when the cryptographic identity of the new key > infrastructure is successfully deployed to the device but the > established secure connection can be used to deploy a locally issued > certificate to the device as well. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-05 > > > 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 > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/anima
