Viewing the last 20 entries. Show full log.

2013-03-26 21:27 Joel Jaeggli

[Ballot comment]
While I'm happy to work to document or ameliorate the Transport area's concern that unicast encapsulation is not sensitive to to congestion control, fundamentally multicast encapsulation never has been. While some applications that leverage multicast are adaptive to loss most are not. AMT doesn't really change that situation.

2013-03-26 21:27 Joel Jaeggli

[Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli

2013-03-13 15:40 Cindy Morgan

Shepherding AD changed to Joel Jaeggli

2013-01-10 10:25 Cindy Morgan

State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation

2013-01-10 09:32 Benoit Claise

[Ballot discuss]
More of a DISCUSS-DISCUSS type of feedback.
This document IANA considerations section should update the IPv4 and IPv6 Special-
Purpose Address Registries (draft-bonica-special-purpose-05), correct?

As discussed during the IESG telechat on Jan 10th, I'm holding the DISCUSS on behalf of IANA (Michelle Cotton) for all IANA issues:
IANA has reviewed draft-ietf-mboned-auto-multicast-14 and has
the following comments:

IANA has questions about the IANA actions requested in this document.

The title of 7.1 is "IPv4 and IPv6 Anycast Prefix Allocation". IANA understands this to mean that the authors actually want unicast prefixes which will be used for anycast routing. RFC 3513, section 2.4 notes that "Anycast addresses are taken from the unicast address spaces (of any scope) and are not syntactically distinguishable from unicast addresses."

IANA believes that 7.1.1 could be more efficiently written as "IANA has assigned 154.7.0/24 for IPv4 AMT Relays."

IANA would also prefer that 7.1.2 should use similar language and we would like to propose 2001:0003::/32 as a prefix.

IANA believes that 7.2 could be more efficiently written as "IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses."

In 7.3 it says "IANA has reserved UDP port number 2268 for AMT." It is not clear to IANA if the authors are asking for a reservation to be turned into an assignment or noting an action that was previously taken and does not need to be modified. IANA has examined the ports registry and can see the registration but no link to an I-D or RFC. Do the authors want the current registrant name to be replaced with this I-D and the RFC number when it is approved?

IANA also believes these prefixes should be registered in the IANA IPv4 and IPv6 Special Registries. It would be helpful if the authors could provide the basic data for the registry in addition to the prefix:

Assignment
Termination Date
Purpose
Contact Details
Routing Scope
Reference

The routing scope is particularly helpful for the future as IANA will use it when developing a set of RPKI objects as defined in RFC 6491.

2013-01-10 09:32 Benoit Claise

Ballot discuss text updated for Benoit Claise

2013-01-10 09:00 Benoit Claise

As discussed during the IESG telechat on Jan 10th, I'm holding the DISCUSS on behalf of IANA (Michelle Cotton) for all IANA issues.

2013-01-10 09:00 Benoit Claise

Ballot discuss text updated for Benoit Claise

2013-01-10 07:36 Benoit Claise

[Ballot comment]
1.
From this figure ...

Isolated Site | Unicast Network | Native Multicast
| (Internet) |
| |
| |
| Group Membership |
+-------+ ===========================> +-------+ Multicast +------+
|Gateway| | | | Relay |<----//----|Source|
+-------+ <=========================== +-------+ +------+
| Multicast Data |
| |
| |

Figure 1: Basic AMT Architecture

... I was not sure whether the left part of the gateway was IP unicast of multicast.
It's only when I saw the following figure that I understood.

Gateway Relay

General _____ _____
___________ Query | | | | Query ___________
| |<------| | | |<------| |
| Host Mode | | AMT | | AMT | |Router Mode|
| IGMP/MLD | | | UDP | | | IGMP/MLD |
|___________|------>| |<----->| |------>|___________|
Report | | | | Report
Leave/Done | | | | Leave/Done
| | | |
IP Multicast <------| | | |<------ IP Multicast
|_____| |_____|

Multicast Reception State Managed By IGMP/MLD

It might be better to clarify it earlier in the draft
The intro mentioned:
AMT enables sites, hosts or applications that do not
have native multicast access to a network with multicast connectivity
to a source, to request and receive SSM [RFC4607] and ASM [RFC1112]
traffic from a network that does provide multicast connectivity to
that source.
So I was thinking: a gateway in every host/applications?
Then the following figure is actually a host
+-----------------------------------------------------+
|Host |
| ______________________________________ |
| | | |
| | ___________________________ | |
| | | | | |
| | | v | |
| | | +-----------+ +--------------+ |
| | | |Application| | AMT Daemon | |
| | | +-----------+ +--------------+ |
| | | join/leave | ^ data ^ AMT |
| | | | | | |
| | | +----|---|-------------|-+ |
| | | | __| |_________ | | |
| | | | | | | | |
| | | | | Sockets | | | |
| | | +-|------+-------+-|---|-+ |
| | | | | IGMP | TCP | |UDP| | |
| | | +-|------+-------+-|---|-+ |
| | | | | ^ IP | | | |
| | | | | | ____________| | | |
| | | | | | | | | |
| | | +-|-|-|----------------|-+ |
| | | | | | | |
| | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) |
| | | v | | v |
| | | +-----------+ +---+ |
| | | |Virtual I/F| |I/F| |
| | | +-----------+ +---+ |
| | | | ^ ^ |
| | | IP(IGMP)| |IP(UDP(data)) | |
| | |_________| |IP(IGMP) | |
| | | | |
| |_________________| | |
| | |
+--------------------------------------|--------------+
v
AMT Relay

Virtual Interface Implementation Example

So clarify early in the draft that the gateway may be a standalone device with muulticast downstream, or a host.

PROPOSAL
OLD
4.1.2. Gateways

The downstream side of a gateway services one or more receivers - the
gateway accepts group membership requests from receivers and forwards
requested multicast traffic back to those receivers.

NEW
4.1.2. Gateways

The downstream side of a gateway services one or more multicast receivers - the
gateway accepts group membership requests from receivers and forwards
requested multicast traffic back to those receivers. The gateway functionality may be
directly implemented in the host requesting the multicast service.

OLD

4.1.5.2. IANA-Assigned Relay Discovery Address Prefix
This document calls for IANA to allocate an anycast address prefix for use in advertising and discovering publicly accessible relays.

NEW:
4.1.5.2. IANA-Assigned Relay Discovery Address Prefix
This document calls for IANA to allocate an anycast IPv4 and IPv- address prefix for use in advertising and discovering publicly accessible relays.

2013-01-10 07:36 Benoit Claise

[Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise

2013-01-10 03:54 Gonzalo Camarillo

[Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo

2013-01-09 17:28 Wesley Eddy

[Ballot comment]
I fully agree with the issues in Martin's DISCUSS.

2013-01-09 17:28 Wesley Eddy

[Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy

2013-01-09 14:50 Robert Sparks

[Ballot comment]
I couldn't find where the document explicitly calls out how to represent the IP addresses in the binary fields - you almost certainly intend for them to be in network-byte-order, but if it's not already explicit in the document, please make it so.

Are there any considerations that the document should call out for administrators for making the transition when the network from which hosts had been using AMT to reach content is given native multicast connectivity?

2013-01-09 14:50 Robert Sparks

[Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks

2013-01-09 12:50 Sean Turner

[Ballot comment]
0) I agree with Martin's 4th discuss (the security one).

1) I agree with Stephen's 1st discuss also.

2) I also agree with Stephen's 2nd discuss, but I've got a bit more:

a) [RFC6151] recommends against the use of MD5 as you've documented it. If you need any kind of collision resistance MD5 is inappropriate to use. If you don't care about collisions resistance, then I think you need to explicitly state that in the security considerations. MD5 is okay to use in an HMAC though, but there are better choices out there for "new" protocols.

b) If you're going to retain the secret key, then some words about protecting the secret are needed. We can revisit this after the dust has settled on Stephen's discusses.

3) And on his "nonce" comment, yeah I really think it's not much of a nonce [RFC4949]:

$ nonce
(I) A random or non-repeating value that is included in data
exchanged by a protocol, usually for the purpose of guaranteeing
liveness and thus detecting and protecting against replay attacks.
(See: fresh.)

4) s5.2.3.4.5/s5.2.3.5.6 and s5.3.6: Add a normative reference to RFC 4086 for randomness requirements. Put it in the sentence that talks about the pseudo-random number generator. It's pretty much the standard motherhood and apple pie statement when it comes to PRNGs.

5) s4.1.3.1: r/is a architectural/is an architectural

6) s4.2.1.2 and elsewhere: r/private secret/secret (secrets are private :)

7) s4.2.2.3: So this is probably nit picking, but isn't I-D.ietf-6man-udpchecksums "the" solution not "a" solution as it's about to be a PS?

8) s5.2.3.4.2/s5.2.3.5.2: Would be good to provide a pointer to the state timers so folks will know how long they need to keep the nonce.

9) s5.3.6: WRT retention, shouldn't the prior secret key be kept until after you start using the new key? App A talks about reauthenticating with the old key?

10) References:

a) Normative:

Pretty sure that in addition to 1321 being normative the following should also be normative:

I-D.ietf-6man-udpchecksums, 2336, 2710 - Even if these are SHOULD/MAY then it's a normative reference. And, you place requirements on IGMPv2 MLD. See IESG statement on informative/normative references. Or, were you thinking the IGMPv3 implementation must support v2 Membership Report & v2 Leave Group in 3376 so you'd leave it information here? I guess same for MLDv2 saying which bits of MLDv1 must be supported?.

RFC 2119 - Pretty sure this is always normative when used.

b) Unused references:

== Unused Reference: 'RFC0768' is defined on line 3366, but no explicit
reference was found in the text

== Unused Reference: 'RFC4605' is defined on line 3385, but no explicit
reference was found in the text

== Unused Reference: 'RFC2104' is defined on line 3418, but no explicit
reference was found in the text

== Unused Reference: 'RFC3053' is defined on line 3439, but no explicit
reference was found in the text

== Unused Reference: 'RFC3056' is defined on line 3442, but no explicit
reference was found in the text

== Unused Reference: 'RFC3068' is defined on line 3445, but no explicit
reference was found in the text

== Unused Reference: 'RFC3973' is defined on line 3452, but no explicit
reference was found in the text

== Unused Reference: 'RFC4760' is defined on line 3464, but no explicit
reference was found in the text

2013-01-09 12:50 Sean Turner

[Ballot Position Update] New position, No Objection, has been recorded for Sean Turner

2013-01-09 10:31 Stewart Bryant

[Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant

2013-01-09 08:52 Ralph Droms

[Ballot comment]
I have one small clarification to ask about. In section 5.3.3.4, in
reference to the text:

The IGMP and MLD protocol specifications indicate that senders SHOULD
use a link-local source IP address in message datagrams. This
requirement must be relaxed for AMT because gateways and relays do
not share a common subnet.

is the requirement being relaxed that senders use a source IP address
of greater than link-scope or that the the relay IGMP and MLD
implementations accept a message with a link-local source IP address
from a sender that is not on-link?

Viewing the last 20 entries. Show full log.

IETF :: mboned

Current state: WG Document