Fwd

[holbrook@cisco.com]

Yikes.  I made a typo in the destination address when I responded to
Pavlin's mail, so this never went out to the list.

-Hugh

------- Forwarded Message -------
From: Hugh Holbrook <holbrook@cisco.com>
To: holbrook@cisco.com
Cc: ssm-interest@external.cicso.com, pavlin@icir.org,
	holbrook@cisco.com, dthaler@microsoft.com
Subject: Re: Fwd: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 
Reply-To: holbrook@cisco.com
Message-Id: <20021213202557.677B710B7A7@holbrook-laptop.cisco.com>
Date: Fri, 13 Dec 2002 15:25:57 -0500 (EST)

Thanks for the detailed comments, Pavlin.

Responses to your non-IPv6 related comments are inline.  I'll follow
up separately with responses to your IPv6 comments.

-Hugh

> ------- Forwarded Message -------
> Message-Id: <200211210052.gAL0qDoo082003@possum.icir.org>
> To: holbrook@cisco.com
> Cc: ssm-interest@cisco.com
> Subject: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 
> Date: Wed, 20 Nov 2002 16:52:13 -0800
> From: Pavlin Radoslavov <pavlin@icir.org>
>
> > There is a new revision of the SSM architecture draft in the ID
> > archives:
> > 
> >       draft-ietf-ssm-arch-01.txt
> > 
> > Please consider this email as notice of an SSM working group last call
> > for comments on this document.  Send comments by 12/9/2002.
> 
> Several comments (in no particular order):
> 
>  * You may want to check the I-D against the nits in
>    http://www.ietf.org/ID-nits.html
>    E.g, don't use citations in the Abstract.

Thanks. I did that.  In addition to the citations that you pointed
out, I added Copyright and IPR sections and changed the example IPv4
addresses to conform to rfc3330 (use 192.0.2.*)

>  * Should the draft include a recommendation that if a host is
>    updated to support SSM, then ASM (*,G) join request by an
>    application for a multicast group that fails within the SSM range
>    should return an error?

I think this is a good suggestion.  Brian and I also discussed
something like this in the context of the IGMPv3/MLDv2 draft.  When we
originally wrote the -arch draft, it was not clear how a host would
really know the SSM address range (other than by configuration).  Now,
there is the (proposed) MRD option for the SSM range advertisement,
and we've put in text about possible manual configuration also.  So I
think it would make sense to specify this.

How about adding the following text to the second to last paragraph of
4.1 (the one that mentions the MSFAPI) as follows:

  When a host has been configured to know the SSM address range, either
  manually or using a protocol, then the host's operating system SHOULD
  return an error to an application that makes a non-source-specific
  request to receive data sent to an SSM destination address.
  
I'm interested in hearing opinions on this from the list.

>  * After enumerating the benefits of the SSM model in Section 1,
>    what about enumerating its limitations/drawbacks? :)

Fair enough.  I'll come up with something.

>  * Reference [IANA-ALLOCATION] should point to
>    http://www.iana.org/assignments/multicast-addresses

Done.

>  * Use consistent notation for the IPv6 hex addresses. E.g., the
>    draft has addresses like FF3x::7fff:ffff which mixes capital with
>    small letters.

Done

> Thanks,
> Pavlin
>