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

On 25/06/2014 19:23, Greg Bumgardner wrote:
> Hi all,
Hi all,
Sorry for the slow response.
>
> 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.
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 <jari.arkko@ericsson.com 
> <mailto:jari.arkko@ericsson.com>> wrote:
>
>     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
>     <alexey.melnikov@isode.com <mailto:alexey.melnikov@isode.com>> 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
>     > Gen-art@ietf.org <mailto:Gen-art@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/gen-art
>
>