Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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" <[e-mail]> 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" <[e-mail]> 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