> -----邮件原件----- > 发件人: Acee Lindem (acee) [mailto:acee@xxxxxxxxx] > 发送时间: 2017年8月22日 2:45 > 收件人: Pete Resnick > 抄送: gen-art@xxxxxxxx; ospf@xxxxxxxx; > draft-ietf-ospf-encapsulation-cap.all@xxxxxxxx; ietf@xxxxxxxx > 主题: Re: Genart last call review of draft-ietf-ospf-encapsulation-cap-06 > > > > 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. Fully agree. Best regards, Xiaohu > 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