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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: 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.
> >
> >>> 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]