Re: Re: [magma] WG Last Call: draft-holbrook-idmr-igmpv3-ssm-05.txt

[Hugh Holbrook <[e-mail]>]

Hi, Pekka.

Thanks for your comments.  I updated the draft to incorporate all of
your suggestions.  An -06 version that incorporates all these changes
as well as a few more bits of wordsmithing should show up in the ID
directory shortly.

See inline for details.

> Date: Mon, 3 Nov 2003 13:32:30 +0200 (EET)
> From: Pekka Savola <[e-mail]>
> 
> On Tue, 28 Oct 2003, Isidor Kouvelas wrote:
> > 	This is the start of a one week WG Last Call to advance
> > draft-holbrook-idmr-igmpv3-ssm-05.txt as a Proposed Standard. This
> > document has had text cleanup and clarification changes made to it as
> > a result of comments from the -04 version Last Call. This Last Call
> > will end on Nov 5, 2003.
> 
> Sorry for missing the LC the last time.  The comments below.
> 
> In summary, I think the document is in a pretty good shape.  However, I 
> think it needs especially more clarification where the document includes 
> modifications or clarifications.  I'd recommend writing clarifications in 
> such a manner that it would be clear they're clarifications.  More 
> comments below..
> 
> substantial
> -----------
> 
> 1) there are several places in the spec which use the uppercase requirements
> language where it's not clear whether it's really just a re-statement of
> some other spec's requirement (then it should be reworded slightly), or
> missing a MODIFICATION tag, for example:
>  - SHOULD in section 2
>  - SHOULD NOT in section 2.2.2
>  - SHOULD in section 2.2.5
>  - MUST in section 2.2.7
>  - everything in section 3.1

I agree with you on this.  I went through and cleaned up the language
substantially.  Every use of RFC 2119 all-caps requirements language
is now very clear as to whether it modifies or merely restates
requirements from IGMPv3/MLDv2.  In doing so, I mostly eliminated the
SHOULD/MAY/MUST language where I was just clarifying, and in a few
cases I left it in but added a phrase like "as required by
[IGMPv3,MLDv2]".

> 2) "SSM-aware host" is defined as a host which has a configuration
> option to manually override the SSM config ranges.  HELLO?!?!  Isn't
> a host which knows the current SSM ranges is equally SSM-aware.  I
> fail to see why you'd have to be able to configure the "SSM-aware"
> club.

That sure wasn't my intention, so I fixed up the text as follows:

  ... A host that knows the SSM address range and is capable of applying SSM
  semantics to it is described as an "SSM-aware" host.
  
  A host or router may be configured to apply SSM semantics to addresses
  other than those in the IANA-allocated range.  The GMP module on a host...
  
> 3) The SSM range for IPv6 is defined in section 2 as FF3x::/32.
> Some others interpret RFC3306 so that the SSM range is FF3x::/96.
> Which is it?  This may need to be clarified somewhere.. maybe
> someone knows what is the appropriate one to use..

We discussed this a while back and the full story is spelled out in
draft-ietf-ssm-arch-04.txt.  I added the following text referring to
that document:

  The 232/8 IPv4 address range is currently allocated for SSM by IANA
  [IANA-ALLOCATION].  In IPv6, the FF3x::/32 range (where 'x' is a valid
  IPv6 multicast scope value) is reserved for SSM semantics [RFC3306],
  although today SSM allocations are restricted to FF3x::/96.  ([SSM] has
  a more thorough discussion of this topic.)

And since you ask here's the longer text from the -arch document:

  For IPv6, the address prefix FF3x::/32 is reserved for source-specific
  multicast use, where 'x' is any valid scope identifier, by [IPV6-UBM].
  Using the terminology of [IPv6-UBM], all SSM addresses must have P=1,
  T=1, and plen=0.  [IPv6-MALLOC] mandates that the network prefix field
  of an SSM address also be set to zero, hence all SSM addresses fall in
  the FF3x::/96 range.  Future documents may allow a non-zero network
  prefix field if, for instance, a new IP address to MAC address mapping
  is defined.  Thus, address allocation should occur within the FF3x::/96
  range, but a system should treat all of FF3x::/32 as SSM addresses, to
  allow for compatibility with possible future uses of the network prefix
  field.
  

> 4) section 2 describes the modifications and defines an "SSM-aware host". 
> Is there a need to do something similar for routers? May be necessary if
> section 3 lists any modifications, not just clarifications.

I think this is a good idea, so I did this and updated the intro and
abstract accordingly.

> editorial
> ---------

I made all of your suggested editorial changes.

Thanks again.

-Hugh


_______________________________________________
magma mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/magma