Re: [OSPF] Genart last call review of draft-ietf-ospf-encapsulation-cap-06

["Acee Lindem (acee)" <[e-mail]>]

On 8/21/17, 12:12 PM, "Pete Resnick" <[e-mail]> wrote:

>On 21 Aug 2017, at 10:58, Acee Lindem (acee) wrote:
>
>> Hi Pete,
>>
>> On 8/21/17, 11:40 AM, "Pete Resnick" <[e-mail]>
>> wrote:
>>
>>> Reviewer: Pete Resnick
>>> Review result: Almost Ready
>>>
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>>
>>> For more information, please see the FAQ at
>>>
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>
>>> Document: draft-ietf-ospf-encapsulation-cap-06
>>> Reviewer: Pete Resnick
>>> Review Date: 2017-08-21
>>> IETF LC End Date: 2017-08-28
>>> IESG Telechat date: 2017-08-31
>>>
>>> Summary: Almost Ready
>>>
>>> The content of this document is fine. However, I think the IANA
>>> registry
>>> stuff
>>> is not ready.
>>>
>>> Major issues:
>>>
>>> I think the registrations other than for Endpoint and Color are
>>> incorrect
>>> and
>>> should not be in this document. Certainly the "Reference" field for
>>> 1, 2,
>>> 5, 6,
>>> and 7 should not be "This document", given that the syntax and
>>> semantics
>>> for
>>> these values are defined in other documents.
>>
>> The authors can fix these.
>
>For 1, 2, 6, and 7, that's easy; the drafts defining the values can do
>the registrations. For 5, the reference would be to an existing RFC that
>doesn't do the registration. I'm not sure what to do about that; perhaps
>register it here and make the reference both 5640 and this document.
>However, when someone goes to update 5640 some day, they're going to
>have to put into the IANA considerations to update both the OSPF and BGP
>registries. I'm not sure how to keep track of that. Perhaps saying that
>this document "Updates: 5640"? That doesn't seem great either.
>
>>> I also think that having things in
>>> this registry which are also used by the BGP registry is asking for
>>> trouble:
>>> You wouldn't want the references for the two registries to get out of
>>> sync.
>>> This seems like a mess to me. Would it be possible for IANA to simply
>>> rename
>>> the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry to "BGP
>>> and
>>> OSPF
>>> Tunnel Encapsulation Attribute Sub-TLVs", and share the registry
>>> between
>>> the
>>> two protocols? Then have this (and other) document(s) add values to
>>> that
>>> registry. That way, the documents that actually define the codepoints
>>> can
>>> be
>>> put into the registry.
>>
>> We’ve already had a protracted discussion on the IANA registries. It
>> is
>> not possible as BGP advertises some of the attributes in BGP
>> communities
>> rather than tunnel attributes (e.g., color).
>
>Yuck. I'll try not to prolong the discussion much further, but did you
>consider the possibility of having some of the attributes appear twice,
>with one saying "For BGP communities only" and the other saying, "For
>OSPF tunnels only"? What a lovely mess. :-(

The cleanest solution is for BGP and OSPF to have their own registries.
Trying to retrofit the existing BGP registry to satisfy OSPF advertisement
requirements is not feasible.

Thanks,
Acee 



>
>> Thanks,
>> Acee
>
>Cheers,
>
>pr
>
>>> Minor issues:
>>>
>>> None.
>>>
>>> Nits/editorial comments:
>>>
>>> In section 7.1, please add:
>>>
>>>   [RFC Editor: Please replace "TBD1" in section 3 with the registry
>>> value
>>>   allocated by IANA, and remove this note].
>>>
>>> That will save them from hunting.
>>>
>
>
>-- 
>Pete Resnick <http://www.qualcomm.com/~presnick/>
>Qualcomm Technologies, Inc. - [phone]