Subject: Re: [Gen-art] Gen-ART review of draft-ietf-mboned-auto-multicast-17

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Jun 2014 16:37:50 +0100

Is there a response to Alexey’s questions?

That being said, ALexey, can you point to what specifically you are worried with in the below arrangement on version numbers? A number version comes along, and those implementations handle other version numbers, while being able to downgrade to 0...

Jari

On 26 May 2014, at 10:47, Alexey Melnikov <[email-masked]> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-mboned-auto-multicast-17
> Reviewer: Alexey Melnikov
> Review Date: May 26, 2014
> IETF LC End Date: May 26, 2014
> 
> Summary:  Nearly ready for publication as a Proposed Standard.
> 
> Major issues:
> 
> 
> In the document, I am seeing:
> 
> 5.1.1.1.  Version (V)
> 
>   [And in several other similar sections]
> 
>   The protocol version number for this message is 0.
> 
> 5.2.3.2.  Handling AMT Messages
> 
>   A gateway that conforms to this specification MUST ignore any message
>   with a Version field value other than zero.
> 
> 5.3.3.1.  Handling AMT Messages
> 
>   A relay that conforms to this specification MUST ignore any message
>   with a Version field value other than zero.
> 
> 
> 
> This might not actually be an issue, if it was discussed in the WG. But I am wondering if the WG thought about versioning, backward compatibility and other related issues.
> How likely is it that a new version of AMT is going to be designed? At the moment the document reads like "we have a stub field for future versions, but we haven't thought about how they are going to be handled yet".
> 
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> 5.3.3.4.  Handling a Membership Update Message
> 
>  o  The computed checksums for the encapsulated IP datagram and its
>      payload MUST match the values contained therein.  Checksum
>      computation and verification varies by protocol; See [RFC0791] for
>      IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6).
> 
> Any recommendation for IPv6 or is it covered by one of the other choices?
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Greg Bumgardner <[email-masked]>
Date: Wed, 25 Jun 2014 11:23:01 -0700

Hi all,

For some reason, I missed Alexey's e-mail, but I do have a response to
these two comments.

Version numbers: As you guessed, the version field is basically a stub. The
version number field was added late in the process "just in case" we need
it to indicate the addition of fields, primarily flag bits. Careful reading
of the spec will reveal that several flags were obviously added late in the
designed process that would not be supported by existing implementations of
the protocol (which, unfortunately, were deployed prior to final design of
the protocol as described by the ID). I've assumed that the issue of
backwards compatibility would be addressed in any subsequent protocol
descriptions that might be produced.

IPv6 checksums. IPv6 doesn't use checksums. The checksum in MLD messages is
computed over a virtual header of IPv6 fields and the MLD payload according
to the rules defined by ICMPv6.

Thanks,

-g.b.

On Wed, Jun 25, 2014 at 8:37 AM, Jari Arkko <[email-masked]> wrote:

> That being said, ALexey, can you point to what specifically you are
> worried with in the below arrangement on version numbers? A number version
> comes along, and those implementations handle other version numbers, while
> being able to downgrade to 0...
>
> Jari
>
> > This might not actually be an issue, if it was discussed in the WG. But
> I am wondering if the WG thought about versioning, backward compatibility
> and other related issues.
> > How likely is it that a new version of AMT is going to be designed? At
> the moment the document reads like "we have a stub field for future
> versions, but we haven't thought about how they are going to be handled
> yet".
> >
> >
> > Minor issues: None
> >
> > Nits/editorial comments:
> >

-- 
Greg Bumgardner
Eugene, OR

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 30 Jun 2014 13:18:11 +0100

> Hi all,
Hi all,
Sorry for the slow response.
> Version numbers: As you guessed, the version field is basically a 
> stub. The version number field was added late in the process "just in 
> case" we need it to indicate the addition of fields, primarily flag 
> bits. Careful reading of the spec will reveal that several flags were 
> obviously added late in the designed process that would not be 
> supported by existing implementations of the protocol (which, 
> unfortunately, were deployed prior to final design of the protocol as 
> described by the ID). I've assumed that the issue of backwards 
> compatibility would be addressed in any subsequent protocol 
I am concerned that if you don't think about versionning now, it would 
be hard to fix it later. Is there any expectation on backward 
compatibility between different versions (e.g. are the same messages 
allowed in future versions or are they allowed to have different format, 
etc.).

But if the WG thinks that new versions are unlikely, then it might be Ok 
to defer this till you need to change the version.
> IPv6 checksums. IPv6 doesn't use checksums. The checksum in MLD 
> messages is computed over a virtual header of IPv6 fields and the MLD 
> payload according to the rules defined by ICMPv6.

Ok, thanks.

Best Regards,
Alexey
>
> Thanks,
>
> -g.b.
>
>
> On Wed, Jun 25, 2014 at 8:37 AM, Jari Arkko <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     That being said, ALexey, can you point to what specifically you
>     are worried with in the below arrangement on version numbers? A
>     number version comes along, and those implementations handle other
>     version numbers, while being able to downgrade to 0...
>
>     Jari
>
>     On 26 May 2014, at 10:47, Alexey Melnikov
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > This might not actually be an issue, if it was discussed in the
>     WG. But I am wondering if the WG thought about versioning,
>     backward compatibility and other related issues.
>     > How likely is it that a new version of AMT is going to be
>     designed? At the moment the document reads like "we have a stub
>     field for future versions, but we haven't thought about how they
>     are going to be handled yet".
>     >
>     >
>     > Minor issues: None
>     >
>     > Nits/editorial comments:
>     >
>     > [email-masked] <mailto:[email-masked]>