On 8/21/17, 12:12 PM, "Pete Resnick" <presnick@xxxxxxxxxxxxxxxx> wrote: >On 21 Aug 2017, at 10:58, Acee Lindem (acee) wrote: > >> Hi Pete, >> >> On 8/21/17, 11:40 AM, "Pete Resnick" <presnick@xxxxxxxxxxxxxxxx> >> 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. - +1 (858)651-4478