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 protected]> 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 <[email protected]> > 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 protected] > > https://www.ietf.org/mailman/listinfo/gen-art > > -- Greg Bumgardner Eugene, OR
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
