I will fix the IANA Considerations section based on your comments. Thanks Med.
Dino > On May 4, 2017, at 11:55 PM, [email protected] wrote: > > Re-, > > I checked the new version and do still think IANA section needs work. > > I won't reiterate those related to the type messages. Below some more > comments: > > * LISP ACT values: there is mismatch between the values in the core text and > those in the IANA registry. The bis document should make it clear what > actions are required to align both. > > Actions for the following are needed: > > (3) Drop/No-Reason: A packet that matches this map-cache entry is > dropped. An ICMP Destination Unreachable message SHOULD be > sent. > > (4) Drop/Policy-Denied: A packet that matches this map-cache > entry is dropped. The reason for the Drop action is that a > Map-Request for the target-EID is being policy denied by > either an xTR or the mapping system. > > (5) Drop/Authentication-Failure: A packet that matches this map- > cache entry is dropped. The reason for the Drop action is > that a Map-Request for the target-EID fails an authentication > verification-check by either an xTR or the mapping system. > > * What is the point in adding flag bits into an IANA section (7.2) while no > IANA action is required out there? > > * Section "LISP Address Type Codes" discuses LCAF, which is managed in a > distinct registry (and it is out of scope of this document). The current > "LISP Address Type Codes" registry is empty, btw. > > * "LISP Algorithm ID Numbers": There is no such registry. Are you referring > to the old "LISP Key ID Numbers". In such case, the text should make it clear > what action are you requiring from IANA. > > > Cheers, > Med > >> -----Message d'origine----- >> De : Dino Farinacci [mailto:[email protected]] >> Envoyé : vendredi 5 mai 2017 08:25 >> À : BOUCADAIR Mohamed IMT/OLN >> Cc : [email protected] list >> Objet : Re: [lisp] Do we need a 8113bis? >> >> I am going to wait for direction from the chairs/AD before making anymore >> changes. I have posted what I thought was a decent compromise that brought >> in ideas from various commenters. >> >> Dino >> >>> On May 4, 2017, at 11:15 PM, <[email protected]> >> <[email protected]> wrote: >>> >>> Re-, >>> >>> The bis document can update these entries and/or add new entries without >> updating RFC8113. Otherwise we would need to update that RFC each time >> there is a document asking for a new assignment (5-7 or 9-14)! >>> >>> Please add a note to the IANA section to ask IANA to update the >> references for these entries to the bis document. >>> >>> Thank you. >>> >>> Cheers, >>> Med >>> >>> De : lisp [mailto:[email protected]] De la part de Dino Farinacci >>> Envoyé : jeudi 4 mai 2017 20:57 >>> À : [email protected] list >>> Objet : [lisp] Do we need a 8113bis? >>> >>> Since the reference in RFC8113 points to RFC6830 for Packet Type >> definitions and we are moving them from RFC6830 to RFC6833bis for the >> data-plane/control-plane document separation effort, should we not have a >> RFC8113bis that points to RFC6883bis? >>> >>> And then RFC8113bis can put in the updated list from RFC6833bis. >> Comments? >>> >>> Dino >>> >>> >>> <image003.png> >>> >>> >>> >>> <image004.png> > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
