Draft: draft-ietf-anima-brski-prm

Commentary: This pull request should be content - free . It should be just a reformat , and I 'll be looking at the github markdown diff to verify . The reason for sentence per line is to make changes easier to see . Turn on paragraph wrap in your editor instead of doing it in the file . Emacs can do this and so can vim . Willing to compromise with wrapped text , but new sentence on new line . 
 please check the text change at : " The manufacturer provided components / services ( MASA and " as I do n't know if I got the point - form indent correct . 
 I just had a review on the changes and they just relating to the formatting in the md file . The open issue in the formatting with the bullet list has been resolved in the design Team meeting on October 28th . I merged the PULL request
If we would amend the assertion with the new agent-proximity enum
value, binary transport would indicate this as a new numerical value,
and string transports would indicate this as the new string value
"agent-proximity".
In both cases, pre-exising voucher implementation would recognize an
unrecognized values and would fail on the voucher, which is exactly
what we want.
Aka: if it was not for the fact that enum are not meant to be
extensible, it seems there would be no issue ?
We are looking for YANG doctor guidance/recommendations for this
issue, boh for how to deal with this extension, but also (ideally)
with the best option how to minimize he overhead when the next
assertion extension comes along.
Ideally, the solution would allow us to automatically get a string
value encoding for string transports and a numerical encoding vor
binary transports.  And new values would just require additions to a
TBD IANA registry we would define into an appropriate draft.
This issue tracked at: #18 Please discuss on anima@ietf.org so the
discussion reaches the whole community.
In contrast to BRSKI the pledge acts as a server component.  It is
triggered by the registrar-agent for the generation of pledge-
voucher-request and pledge-enrollment-request objects as well as for
the processing of the response objects and the generation of status
information.  Due to the use of the registrar-agent, the interaction
with the domain registrar is changed as shown in exchangesfig_uc2_1.
To enable interaction with the registrar-agent, the pledge provides
endpoints using the BRSKI interface based on the "/.well-known/brski"
URI tree.
The discovery of the pledge by registrar-agent should be done by
using DNS-based Service Discovery RFC6763 over Multicast DNS RFC6762
to discover the pledge at "product-serial-number.brski-
pledge._tcp.local."  The pledge constructs a local host name based on
device local information (product-serial-number), which results in
"product-serial-number.brski-pledge._tcp.local.".  It can then be
discovered by the registrar-agent via mDNS.  Note that other
mechanisms for discovery may be used.
The discovery of the pledge by registrar-agent should be done by
using DNS-based Service Discovery RFC6763 over Multicast DNS RFC6762
to discover the pledge at "product-serial-number.brski-
pledge._tcp.local."  The pledge constructs a local host name based on
device local information (product-serial-number), which results in
"product-serial-number.brski-pledge._tcp.local."  It can then be
discovered by the registrar-agent via mDNS.  Note that other
mechanisms for discovery may be used.
with an empty body.
The registrar-agent pledge-enrollment-request Content-Type header is:
"application/json" with an empty body.
application/voucher-jws+json (see pvr for the content definition).
If validation fails, the MASA SHOULD respond with an HTTP error code
to the registrar.  The error codes are kept as defined in section 5.6
of RFC8995.  and comprise the response codes 403, 404, 406, and 415.
If validation fails, the MASA SHOULD respond with an HTTP error code
to the registrar.  The error codes are kept as defined in section 5.6
of RFC8995, and comprise the response codes 403, 404, 406, and 415.