Re: [Int-dir] Intdir last call review of draft-ietf-ippm-alt-mark-10

["Carlos Pignataro (cpignata)" <[e-mail]>]

Please find two comments inline.

On Sep 20, 2017, at 11:16 AM, Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> wrote:

Just on the mechanics -

On Wed, Sep 20, 2017 at 9:50 AM, Fioccola Giuseppe <[e-mail]<mailto:[e-mail]>> wrote:
Hi Brian,
Ok, Thank you!

Giuseppe

-----Messaggio originale-----
Da: Brian Haberman [mailto:[e-mail]<mailto:[e-mail]>]
Inviato: mercoledì 20 settembre 2017 16:29
A: Fioccola Giuseppe; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Oggetto: Re: R: Intdir last call review of draft-ietf-ippm-alt-mark-10

Hi Giuseppe,
     I am fine with your proposed changes, but I would recommend that you wait until the AD or doc shepherd indicate that the changes be made.

Giuseppe has responded to his reviewer with proposed text changes, and (even better) has feedback from his reviewer.

That's what matters most. Submitting an update at that point is often harmless, but risks getting feedback from other reviewers, and from the IESG, that touches the same text, so then the editor is left to mix everything together and have a coherent update come out. Even worse, it can happen that you get different ADs balloting on different versions of the draft and providing comments that other ADs have to analyze when balloting. So, waiting for the telechat, and submitting one update that addresses the comments received, is fine with me.

Indeed the important part is the dialogue and convergence.

As shepherd, for contrast, I tend to prefer different mechanics: revision numbers are really cheap, and submitting new revisions in response to I-D reviews  with a release-early-release-often approach (instead of bundling main features) has important benefits. The rational is that an editor likely has changes incorporated in her or his working copy, and the next reviewer (Directorate, AD, etc) will likely comment on the same issue. It is also easier to identify where fixes are applied as it simplifies tracking. The exception is during actual ballot where there’s a large number of reviews in a very short timeframe.


Other ADs might have other preferences for a specific draft, but since this one's mine, let's go with my opinion for now :D …

I was just sharing for contrast, clearly let’s go with Spencer’s preference and guidance on this.


Spencer




[…]

>
> Reviewer: Brian Haberman
> Review result: Ready with Nits
>
> * The shepherd writeup mentions IPR 2557 in relation to this draft. However, the IPR declaration is only associated with the original individual draft. The IPR declaration needs to be updated to refer to the WG draft.
>
> [GF]: If needed we can renew the IPR declaration to refer to the WG draft.
>

It might not hurt, but at the same time, a question:

RFC 8179 S 5.4.2 talks about inheritance of IPR disclosures:
https://tools.ietf.org/html/rfc8179#section-5.4.2

      IPR
      disclosures against a particular Contribution are assumed to be
      inherited by revisions of the Contribution and by any RFCs that
      are published from the Contribution unless the disclosure has been
      updated or withdrawn.

It is not clear if a “revision” of an I-D as a contribution includes renaming it as WG document, merges, etc.

The data tracker tooling seems to be coded such that, if there is a Replaced_by relationship, the IPR declaration follows:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-ippm-alt-mark
“Total number of IPR disclosures found: 1."

And contributors all acknowledged IPR 2557.

So the question:

> * The shepherd writeup mentions IPR 2557 in relation to this draft. However, the IPR declaration is only associated with the original individual draft. The IPR declaration needs to be updated to refer to the WG draft.


Does it carry forward?

Thanks,

— Carlos.

>
> Rispetta l'ambiente. Non stampare questa mail se non è necessario.
>