> Dino, > >>> This is the last part of my review, as far as the actual document contents >>> go. I will send another summary e-mail. >>> >>> Technical: >>> >>>> 14.1. LISP Address Type Codes >>>> >>>> Instance ID type codes have a range from 0 to 15, of which 0 and 1 >>>> have been allocated [LCAF]. New Type Codes MUST be allocated >>>> starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. >>>> Type Codes 11 - 15 are available on a First Come First Served policy. >>>> >>>> The following codes have been allocated: >>>> >>>> Type 0: Null Body Type >>>> >>>> Type 1: AFI List Type >>>> >>>> See [LCAF] for details for other possible unapproved address >>>> encodings. The unapproved LCAF encodings are an area for further >>>> study and experimentation. >>> To begin with, I did not understand this definition. I'm trying to >>> understand where the LCAF draft actually makes the instance ID allocations, >>> and I can't see it. In addition, the "Null Body Type" string only appears >>> twice in this and the LCAF draft, and neither occurrence explains what it >>> is. I think something is missing here. >> The source-EID in an RLOC-probe may contain a null body encoding. Because >> there was no data packet that triggered this Map-Request. I will add that to >> the RLOC-probe section. >> >> Instance-ID is defined in the LCAF draft as Type 2. Here is the packet >> format: >> >> Instance ID LISP Canonical Address Format: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI = 16387 | Rsvd1 | Flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type = 2 | Rsvd2 | 4 + n | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Instance ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI = x | Address ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Length value n: length in bytes of the AFI address that follows the >> Instance ID field including the AFI field itself. >> >> Instance ID: the low-order 24-bits that can go into a LISP data >> header when the I-bit is set. See [LISP] for details. >> >> AFI = x: x can be any AFI value from [AFI]. >> >> This LISP Canonical Address Type can be used to encode either EID or >> RLOC addresses. >> >>> Finally, I do not understand why this section is in -lisp. The string "LISP >>> Address Type Code" does not appear in the rest of the document AFAICT. The >>> allocations in the LCAF draft seem to be inside a format defined in that >>> draft. Shouldn't the IANA allocations and the creation of the registry be >>> in that draft as well? This seems particularly important, given that the >>> list of types in -lisp does not match the list in -lcaf. >> We (the working group) have decided to put the in-charter values in this >> draft and keep the other values in the LCAF draft. So that is why values 0 >> and 1 are in this draft. Since instance-ID is part of a VPN use-case, this >> is why it is the next value assigned in the LCAF draft. >> >> We received direction from Terry on this since he is expert in registries et >> al. > > I now understand the background, thank you for the explanation. But I think > the WG still made the wrong call on this. > > I would like to play the manager who tells you that the we need to ship your > product and this feature still has bugs in it. Lets rip it out and not > endanger our release schedule. In other words, I think other people will have > the same questions as I did about this part and there is no technical reason > why it needs to be here. I don't think the text is harmful by itself, but I > predict unnecessary questions. Lets remove it and move on.
That is not what's going on here. How about we have an iPhone that has a Settings configruation for screen size and one of the values is a resolution that is larger than the iPhone screen size? What it means, is that something larger is about to come. This is an experimental protocol. We are still doing the experiment and the chairs wanted to make it easy for us to experiment with new use-cases, even though out of charter. But they may come into charter in the future. So let's make sure we don't let the IETF process get the best of us. >> >>> Suggested edit: delete this section. >>> >>>> o The following policies are used here with the meanings defined in >>>> BCP 26<http://tools.ietf.org/html/bcp26>: "Specification Required", >>>> "IETF Consensus", "Experimental >>>> Use", "First Come First Served". >>>> >>> None of these terms are used in the rest of the document. (But see below.) >> That is Terry text and seems to be standard. > > The standard model for this text is to include the terms that are used in > subsequent text. In any case, the terms above are also outdated after RFC > 5226 came out. > > I've taken this into account in my next proposed change (see below) and if > you use that text you do not need the above text any more. > >> >>>> 14. IANA Considerations >>> This sections makes the right allocations from other, already existing >>> registries (like UDP port numbers). But it should also define what the >>> policies are for allocating new values with the various new number spaces >>> that Lisp introduces: >>> >>> - flags >>> - type >>> - reserved >>> - act >>> - unused flags >>> - … >> Terry needs to respond to this. > > I'm not sure if we have seen a response, but I also don't think it is hard to > develop the text for this. This one needs to go in, because otherwise we > don't know how to manage the name spaces. It is a potential Discuss item from > the other ADs or even IANA if the process isn't clear. Here's a strawman text: We have not. I want to wait for Terry to respond. Dino > > IANA should create a registry for managing the new namespaces within the LISP > protocol. This registry contains initially the following two new namespaces. > > o New LISP Type values (Section 6.1.1) can be allocated through IETF Review > or IESG Approval <xref target="RFC5226"/>. Six values have already been > allocated by this specification (Section 6.1.1). > > o New ACT values (Section 6.1.4) can be allocated through IETEF Review or > IESG Approval. Four values have already been allocated by this specification > (Section 6.1.4). > > In addition, the LISP protocol has a number of flag and reserved fields, such > as the LISP header flags field (Section 5.3). New bits for flags can be taken > into use from these fields through IETF Review or IESG Approval, but these > need not be managed by IANA. > > Jari > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
