On Wed, Sep 26, 2018 at 10:25:54PM +0000, Acee Lindem (acee) wrote: > Hi Ben, Authors, > > On 9/26/18, 6:20 PM, "Benjamin Kaduk" <[email protected]> wrote: > > Hi Acee, > > On Wed, Sep 26, 2018 at 10:14:21PM +0000, Acee Lindem (acee) wrote: > > Hi Ben, > > > > On 9/26/18, 6:02 PM, "Benjamin Kaduk" <[email protected]> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-ospf-segment-routing-msd-21: Discuss > > > > When responding, please keep the subject line intact and reply to > all > > email addresses included in the To and CC lines. (Feel free to cut > this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/ > > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > This is essentially a process discuss, and hopefully easy to > resolve. > > > > In Section 4, we say: > > > > The meaning of the absence of both Node and Link MSD > advertisements > > for a given MSD type is specific to the MSD type. Generally it > can > > only be inferred that the advertising node does not support > > advertisement of that MSD type. However, in some cases the lack > of > > advertisement might imply that the functionality associated with > the > > MSD type is not supported. The correct interpretation MUST be > > specified when an MSD type is defined. > > > > I don't think we can make this sort of normative requirement on a > registry > > created by a different document, at least not without updating the > registry > > to also point to this document. > > > > Would you be satisfied if the same text were in both the IS-IS and OSPF > document? We really want a copy registry for IGPs (which are really only > disseminating the information) to Segment Routing capable routers in the > routing domain. > > I think that depends on which text you're thinking about. In particular, > I > also asked for the IS-IS document to include in the IANA considerations > some guidance to the experts that the experts need to check this > requirement, and I'm not sure if that would result in just adding text to > the IANA considerations or also removing text from earlier in the > document. > > On a slightly different note, we do occasionally have things like "[this > other document] placed some requirements on [foo]. Those requirements > also > apply here, so we are copying the following paragraph from [this other > document] below for the convenience of the reader", and I could see a > copy+reference working here. > > So, if the other document enforces the normative requirement we need, but > we want to call attention to the requirement in this document as well, > copying the text with a note about where it came from should suffice. > > I think this is the best path since we want the documents to be independent > of one another even though they share the registry and semantics. If we'd > have merged the OSPF and IS-IS WGs earlier, we'd have had a single document > and have done so with the Flex Algorithm draft.
Indeed, and sorry for having to toss a stumbling block in the works. -Benjamin _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
