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

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 <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>
> 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
> > https://www.ietf.org/mailman/listinfo/gen-art
>
>

-- 
Greg Bumgardner
Eugene, OR