Subject: [pim] Draft email to IESG on draft-ietf-pim-explicit-tracking

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Jan 2014 20:09:36 -0000

Should probably come from the document shepherd once all is agreed.

===

Hi IESG,

Thanks for your reviews and Comments on draft-ietf-pim-explicit-tracking. Adrian
has brought these back to the PIM WG and we are concerned to address the cause
of the Abstentions by discussing the situation with you and by making some
modifications to the text.

Firstly to let you know that although this I-D started off as Informational it
was moved to Standards Track after some debate in the working group. Various
reasons were advanced, but we consider the most important one to be that the
document describes function that is important for the scalability of multicast
networks, already widely implemented, and which could seriously break IGMP/MLD
if not implemented correctly. In this respect, we see this work as similar to
RFC 4605 which was also published as Standards Track.

While we appreciate your concerns that there are many ways to implement this
function (and, indeed, there are many different existing implementations), we
believe that there is a core statement of what must and must not be done in
order to avoid breaking interoperability. That is, although there is no
description of on-wire behavior that must be implemented to achieve
interoperability, this document describes things that must be done if this
function is used and interoperability is to be retained.

We think that the document could be clearer about this. In particular, we think
that we should make a clearer distinction in the text between:
- the description of the problem
- the objective and overview of the function
- statements about what implementations must/should/etc. do
- an example set of procedures that an implementation could follow if it wants
to be sure of being safe.
We don't expect that this clarification work will result in substantial changes
to the text, but will mean some changes to the sections, and a few clarifying
sentences. But we do believe that the resulting document should continue as
Standards Track.

In view of this, we suggest that you delay your consideration of the document
until we have produced a new revision.

===

Please note: I am floating this text, not dictating it! If the WG does not
agree, then the WG needs to speak up.

Cheers,
Adrian

> -----Original Message-----
> From: pim [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 07 January 2014 19:54
> To: 'Stig Venaas'; [email-masked]
> Cc: [email-masked]
> Subject: Re: [pim] <draft-ietf-pim-explicit-tracking-09.txt> updated by Cindy
> Morgan
> 
> Thanks again Stig,
> 
> I'm going to play devil's advocate here because I know that various ADs will
ask
> the hard questions. I also know that you are trying to represent what you
heard
> in the WG (so we are both arguing representative corners rather than our own
> positions - perhaps we could get jobs playing lawyers on TV).
> 
> > > Thanks or this explanation. I can appreciate the points you make. Indeed,
> > > one of the things I tried to explain to the IESG was that getting this
wrong
> > > could break interoperability.
> > >
> > > The counter argument made to me was that there are many ways to
> > > achieve the function and that (as far as the ADs knew) none of the
> > > existing implementations (some of which are quite old) actually does
> > > what this draft describes. Maybe the
> >
> > Yes, there are multiple ways of doing this. I think existing
> > implementations are close to what the draft specifies (with
> > some variations and not all that is mentioned here).
> 
> Hmmm. OK.
> So we have "Here is a document that describes something similar to what some
> implementations do to achieve this function."
> 
> > This draft started out as informational, and my understanding of
> > this was that we view this as important functionality and that it
> > was worth describing how to implement it in a good way. That sounds
> > like a typical informational draft to me.
> 
> Yes.
> So let's work though the reasoning below before I say "I agree. Let's make
this
> Informational and be done with it."
> 
> > The main reasons it was changed to standards track are roughly:
> >
> > 1. It is a very useful feature and widely implemented and deployed.
> 
> That is without doubt.
> But that is not a reason for Standards Track especially since the document
> doesn't describe precisely what is implemented and deployed.
> 
> > 2. Interoperability. IGMP/MLD may break if not implemented correctly.
> >     There have been examples of this done wrong I think (although I
> >     cannot remember for sure now. There have been issues with various
> >     snooping/proxy implementations where explicit tracking is one part).
> 
> I think this is the strongest claim.
> There are some uses of 2119 language (not many) in the I-D, and it is my take
> that ignoring those would break interop.
> We could improve the standing as Standards Track if we made a stronger case
for
> this I-D setting guidelines that implementations of this function must follow.
> 
> > 3. There are other documents that are/were planned for standards track
> >     referencing it.
> 
> That is pretty poor as a reason.
> Normative references can and are made to Informational RFCs from Standards
> Track
> documents.
> 
> > I think 1 was the main argument brought up in the meeting (see the
> > minutes included below), but IMO 2 is the strongest argument for PS.
> > 3 is not that strong as it is still possible to reference it (just more
> > difficult).
> 
> OK.
> We reached the same conclusions.
> 
> > > issue here is that there is a difference between:
> > > - black-box behavior
> > > - principles of operation of the function
> > > - sample (example) mechanism.
> >
> > I guess the concern here might be that existing implementations might
> > work fine, but not necessarily follow this draft, and that there are
> > several valid ways to implement it. But a lot of what is described in
> > the document is not required, it talks about several ways things can
> > be done. It only uses requirements language in a few places where I
> > think it is really needed. Note that there were key people from
> > different vendors stating that they wanted it standards track.
> >
> > > OK. It seems that there is history in the WG for considering this as
> Standards
> > > Track so we need to construct a message to the IESG about why this is
> > > reasonable.
> >
> > I mentioned RFC 4605 here, which is PS and came out of magma with Brian
> > as one of the authors. There are similarities between that document and
> > this, and both have some normative language required to not break the
> > IGMP/MLD protocols.
> >
> > Happy for input from others in the group, but I believe the WG wants it
> > to be standards track.
> >
> > > Anyone want to take a first cut at that or shall I?
> >
> > I think it would be helpful if you can do at least a very rough first
> > cut, giving us an idea what points are worth bringing up.
> 
> OK. That will follow. But I think it is also going to result in some reworking
> of the draft to make it clear what is necessary/advised to avoid breaking
stuff,
> and what is a descriptive example of how the function could be achieved within
> that guidance.
> 
> Cheers,
> Adrian
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Stig Venaas <[email-masked]>
Date: Wed, 08 Jan 2014 15:28:47 -0800

> Should probably come from the document shepherd once all is agreed.

This looks reasonable to me. I agree that the draft can be improved as
you suggest.

Anyone else in the WG (including the author) got any comments? Should I
as the document shepherd send this to the IESG?

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 09 Jan 2014 12:17:03 +0900 (JST)

Hi Adrian and Stig,

I greatly appreciate your efforts, and also agree to the following
explanation.
Thank you.

Regards,
--
Hitoshi Asaeda

Subject: [pim] Draft email to IESG on draft-ietf-pim-explicit-tracking
Date: Tue, 7 Jan 2014 20:09:36 -0000

---

From: Stig Venaas <[email-masked]>
Date: Thu, 09 Jan 2014 10:17:19 -0800

> I greatly appreciate your efforts, and also agree to the following

Good. Adrian, can I just send the text you wrote then?
Thanks a lot for writing that, it looks good to me.

Stig

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Jan 2014 18:39:11 -0000

> Thanks a lot for writing that, it looks good to me.

I'm good with that (bearing in mind that it commits the WG/authors to do a
little jiggling of the document - I'm happy to help with that).

A