Re: [pim] AD Review of draft-ietf-pim-igmp-mld-extension-04

[Stig Venaas <[e-mail]>]

Hi again Alvaro

As an author, I am certainly happy to remove the updates text if it is
not needed. I'll go through your other comments and see how to address
them.

Thanks for the review,
Stig

On Fri, Sep 10, 2021 at 12:03 PM Alvaro Retana <[e-mail]> wrote:
>
>
> Brian/Stig:
>
> Hi!
>
> The good (and also the bad) news is that there is no well-defined interpretation of Updates [1], which means that we can interpret it (almost) any way we want, but others can too.   IOW, there isn't an established set of rules, even if some are common (but subject to interpretation).
>
>
> I don't think that draft-ietf-pim-igmp-mld-extension has to change this piece of text from the Additional Data sub-sections: "...an IGMPv3|MLDv2 implementation MUST NOT include additional octets beyond the fields described here."   The TLVs take the place of the Additional Data so there's no change (no net-new fields are specified), and an rfc3376/rfc3810 implementation wouldn't be able to tell the difference.
>
> It is true that in general (but not always) a base document is Updated when the reserved fields are modified.  It is too bad that a registry wasn't created (back in the original documents) -- then we wouldn't have to worry about this point.
>
>
> My biggest concern is this:  Updates is not consistently defined -- a reasonable interpretation [*] is to consider the extension a required feature in rfc3376/rfc3810 -- this new feature could be seen as a significant change to the base protocols (it is!) resulting in not being able to get rfc3376bis/rfc3810bis to Internet Standard because of the change, but also because there won't be significant experience with it.
>
> I realize that I am making assumptions (and maybe planning for the worst): I don't know how the IESG will interpret the Updates tag when rfc3376bis/rfc3810bis get there.
>
>
> Alvaro.
>
>
> [1] https://datatracker.ietf.org/doc/draft-kuehlewind-update-tag/
>
> [*] That is usually how I interpret it.
>
>
> On September 10, 2021 at 1:04:35 PM, Stig Venaas ([e-mail]) wrote:
>
> Hi Alvaro and Brian
>
> As you noted Brian, when supporting this it would require relaxing at
> least that one rule. Also, don't we generally make it an update when
> we define use of previously reserved bits?
>
> Note that any implementation of the existing IGMPv3/MLDv2 would ignore
> this extension, which is what we want. But if an implementation is to
> send messages using the new extension, it would have to deviate from
> some existing text in e.g. 3376.
>
> I believe this is similar to e.g. reserved bits in general. A base
> protocol RFC would typically define reserved bits with text about how
> they must be set to 0 and ignored, in order to allow future
> extensions. Then new documents would say that you would set some of
> these bits in certain cases, hence deviating from the base RFC
> requirements. Wouldn't we then say that the new draft updates the old
> one? What is the general procedure?
>
> In this case we are also talking about sending additional octets, but
> it is essentially the same as reserved bits. 3376 says to not send
> additional data, but also to ignore the data if present.
>
> Thanks,
> Stig
>
>
>
>
> On Fri, Sep 10, 2021 at 5:10 AM Brian Haberman <[e-mail]> wrote:
> >
> > Hey Alvaro,
> >
> > On 9/9/21 5:15 PM, Alvaro Retana wrote:
> > > Dear authors:
> > >
> > > Thank you for this document!
> > >
> > > In general, I think this document is in good shape -- I do have
> > > comments and suggestions below (inline) that I would like to see
> > > addressed before publication.
> > >
> > > My main concern is the formal Update of rfc3376 and rfc3810. Do we
> > > really need to formally Update those documents? I didn't see a
> > > specific discussion on the list about this topic.
> > >
> >
> > I think the WG needs to think about this a bit given that we are in the
> > process of publishing 3376 and 3810 updates in order to move them to
> > Internet Standard. In general, I agree with the sentiment that optional
> > extensions do not need to update the base specification. However, we may
> > have an issue here as section 4.1.10 of 3376 states:
> >
> > ... When sending a Query,
> > an IGMPv3 implementation MUST NOT include additional octets beyond
> > the fields described here.
> >
> > This extension document has to relax that rule in 3376 IMO.
> >
> > We can't add the necessary extension text to the -bis drafts if we want
> > to make them Internet Standards.
> >
> > Regards,
> > Brian
> >
> > _______________________________________________
> > pim mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pim
>
> _______________________________________________
> pim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pim