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

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

Hi Pete, 

One more inline since Xiaohu must have missed your other comment.

On 8/23/17, 9:21 PM, "Xuxiaohu" <[e-mail]> wrote:

>
>
>> -----邮件原件-----
>> 发件人: Acee Lindem (acee) [mailto:[e-mail]]
>> 发送时间: 2017年8月22日 2:45
>> 收件人: Pete Resnick
>> 抄送: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> 主题: Re: Genart last call review of draft-ietf-ospf-encapsulation-cap-06
>> 
>> 
>> 
>> 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.

Actually, this document does assign these code points in the registry so
“This document” is appropriate. The value portion of these TLVs just
happened to be described via a reference rather than text.

Thanks,
Acee 




>> >
>> >>> 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. - [phone]
>