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