Re: [lisp] AD review of draft-ietf-lisp- reference categories

Dino, are any of these ones we asked you to move around earlier for some 
reason?  (I want to try to avoid saying A, no B, no A...)

Assuming these were not previously moved for some reason, I am happy 
with most of Jari's suggests.

I do think referencing the registry for AFIs is the right thing. 
Referencing the RFC that defines the registry would merely cause an 
indirection, since what people generally need is the values.  If they 
need the underlying definition, they can follow the links from there.

I do not think the Interworking draft should be a normative reference. 
It is needed for understanding deployment with interworking.  But it is 
not needed for understanding the base LISP spec.

Yours,
Joel

On 10/27/2011 12:54 PM, Dino Farinacci wrote:
...
> Terry needs to respond to this.
>
>>>     [BGP-SEC]  Lepinski, M., "An Overview of BGPSEC",
>>>                draft-lepinski-bgpsec-overview-00.txt<http://tools.ietf.org/html/draft-lepinski-bgpsec-overview-00.txt>   (work in progress),
>>>                March 2011.
>>>
>>>     [KARP]     Lebovitz, G. and M. Bhatia, "Keying and Authentication for
>>>                Routing Protocols (KARP)Design Guidelines",
>>>                draft-ietf-karp-design-guide-02.txt<http://tools.ietf.org/html/draft-ietf-karp-design-guide-02.txt>   (work in progress),
>>>                March 2011.
>>
>>>     [RPKI]     Lepinski, M., "An Infrastructure to Support Secure
>>>                Internet Routing",draft-ietf-sidr-arch-13.txt<http://tools.ietf.org/html/draft-ietf-sidr-arch-13.txt>   (work in
>>>                progress), February 2011.
>>
>>
>> I have a hard time seeing why these should be normative references. They are just mentioned as work that is in progress in securing the routing system. You do not need to read these to implement LISP as specified in this document, or even to understand what Lisp is or its impacts.
>
> Can yo and the chairs argue over this and make a decision. Then I will put it where you have agreed.
>
>>>     [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
>>>                STD 13,RFC 1034<http://tools.ietf.org/html/rfc1034>, November 1987.
>>>
>>
>> If you look at the way this is referenced from the text, it is clear that this should be a non-normative reference.
>>
>>       The host obtains
>>       a destination EID the same way it obtains an destination address
>>       today, for example through a Domain Name System (DNS) [RFC1034]
>>       lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.
>>
>>>    [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>>>               A., Peterson, J., Sparks, R., Handley, M., and E.
>>>               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>>>               June 2002.
>>
>> Same as above.
>>
>>>     [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
>>>                Traina, "Generic Routing Encapsulation (GRE)",RFC 2784<http://tools.ietf.org/html/rfc2784>,
>>>                March 2000.
>>>
>>
>> If you look at the way this is referenced from the text, I think this should be a non-normative reference.
>>
>>   o  On an ITR, prepending a new IP header consists of adding more
>>       bytes to a MAC rewrite string and prepending the string as part of
>>       the outgoing encapsulation procedure.  Routers that support GRE
>>       tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
>>       support this action.
>>
>> GRE is here use as an example, not as normative behavior.
>>
>>>     [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
>>>                via IPv4 Clouds",RFC 3056<http://tools.ietf.org/html/rfc3056>, February 2001.
>>>
>>
>> Same as above.
>>
>>>
>>>     [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
>>>                Optimization for Mobile IPv6",RFC 4866<http://tools.ietf.org/html/rfc4866>, May 2007.
>>
>> I think this one can be non-normative or even be removed, depending on how the mobility section rewrite goes.
>>
>>>
>>>     [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
>>>                Workshop on Routing and Addressing",RFC 4984<http://tools.ietf.org/html/rfc4984>,
>>>                September 2007.
>>>
>>
>> Background. Non-normative.
>>
>>>     [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
>>>                NUMBERS
>>>                http://www.iana.org/assignments/address-family-numbers.
>>>
>>>     [AFI-REGISTRY]
>>>                IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
>>>                NUMBER registryhttp://www.iana.org/assignments/
>>>                address-family-numbers/
>>>                address-family-numbers.xml#address-family-numbers-1.
>>
>> Is there really no better reference for this, an RFC perhaps?
>>
>> I wish there were... and that RFC could be put in to the normative-reference section. If there is no suitable RFC I'm fine with the current two references as-is.
>>
>>>     [INTERWORK]
>>>                Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
>>>                "Interworking LISP with IPv4 and IPv6",
>>>                draft-ietf-lisp-interworking-02.txt<http://tools.ietf.org/html/draft-ietf-lisp-interworking-02.txt>   (work in progress).
>>>
>>
>> I think this one should be normative. This is such a key piece of work to understanding Lisp, and the text seems to treat it as if it is a normative part. For instance:
>>
>>   Proxy ITR (PITR):   A PITR is also known as a PTR is defined and
>>       described in [INTERWORK], a PITR acts like an ITR but does so on
>>       behalf of non-LISP sites which send packets to destinations at
>>       LISP sites.
>>
>>>     [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
>>>                draft-ietf-lisp-ms-09.txt<http://tools.ietf.org/html/draft-ietf-lisp-ms-09.txt>   (work in progress).
>>>
>>
>> Isn't this normative as well? Here's an example of how the text refers to it:
>>
>>   Map-Requests can also be LISP encapsulated using UDP destination port
>>    4342 with a LISP type value set to "Encapsulated Control Message",
>>    when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
>>    LISP encapsulated the same way from a Map-Server to an ETR.  Details
>>    on encapsulated Map-Requests and Map-Resolvers can be found in
>>    [LISP-MS].
>
> You guys decide where all of this should go (from my last comment to this line), and I'll make one change.
>
>>>     [VERSIONING]
>>>                Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
>>>                Versioning",draft-ietf-lisp-map-versioning-01.txt<http://tools.ietf.org/html/draft-ietf-lisp-map-versioning-01.txt>   (work
>>>                in progress).
>>>
>>
>> I suspect this is normative, too. See Section 6.6.3.
>>
>> Jari
>
> Dino
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>