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

[Alvaro Retana <[e-mail]>]

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