Subject: Re: [pim] Trying to clean-up an SSM Errata Report

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 May 2013 11:25:40 -0700

Let me add mboned and the author of said errata.

The author of this errata seems to claim inconsistency between 4607 and
prior addressing standards (RFC3307, RFC4291). He also states: "I'm sure that
RFC 4291 should NOT be called in question.". This to me implies that he is asking
to have RFC4607 updated to remove these conflicts in RFC4607bis.

IMHO:

I have not been able to (in)validate the erratas author claims wrt. to
the interpretation of the prior RFCs. I hope others on the lists can chime
in. Assuming he is right on one or the other accounts:

I would like to see a resolution that minimizes actual deployment/interoperability
problems.

Withdrawing address ranges deemed to be useable according to existing RFC4607
in an upcoming RFC4607bis definitely has the potentialy to create mayor 
disturbances in deployments relying on those addresses. If MBoned can clearly
identify affected ranges known not to be deployed at all, then they could be
redesignated, otherwise IMHO not.

I have not seen any example of actual deployment/interoperability issues
from the incompatibility of existing RFC4607 and its claimed conflicts
with prior address architectures. It would be good if the author of the errata
(or someone else) could provide some example of such breakage.

If no real breakage could reasonably be claimed, i think RFC4607bis should
grandfather in the ranges from RFC4607 and explain how we derived at them,
and that they constitute unfortunate, but not caught violations of
principle due to the a) human nature, b) IETF process or c) the complexity
of the IPv6 address architecture. And grandfathering is not the same as
questioning RFC4291.

Cheers
    Toerless

On Sat, May 11, 2013 at 05:36:53PM +0100, Adrian Farrel wrote:
> Hi,
> 
> Take a look at http://www.rfc-editor.org/errata_search.php?eid=905
> 
> I can't make head or tail of what the appropriate resolution is. Advice please.
> 
> And any ideas if there is a better place to discuss this.
> 
> Thanks,
> Adrian
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Stig Venaas <[email-masked]>
Date: Mon, 13 May 2013 10:21:05 -0700

Hi

> to have RFC4607 updated to remove these conflicts in RFC4607bis.

Med (copied) and I are trying to get some of these issues resolved, we
have one draft (draft-ietf-6man-multicast-addr-arch-update) that will
try to clarify and resolve some conflicts. We intent to discuss some of
these SSM issues mentioned here as well. We will probably both on the
list and in the next IETF meeting try to discuss some of these issues.

We've been focusing on how the flag bits are used, and one of the cases
is the use of the transient flag and SSM.

Perhaps this thread is a good opportunity to move forward on this topic.
One question in particular, is whether the T bit should be allowed to be
0 for SSM, and whether the IANA SSM assignments (non-yet) should have
T=0.

Stig