RE: APPSDIR review of draft-ietf-mboned-64-multicast-address-format-01

[<[e-mail]>]

Dear Carsten,

Thank you for the review. 

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : Carsten Bormann [mailto:[e-mail]] 
>Envoyé : dimanche 6 mai 2012 22:58
>À : 
>[e-mail]
>g; [e-mail] application-layer protocols
>Cc : The IESG; [e-mail]; [e-mail]
>Objet : APPSDIR review of 
>draft-ietf-mboned-64-multicast-address-format-01
>
>I have been selected as the Applications Area Directorate reviewer for
>this draft (for background on appsdir, please see
>http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaD
>irectorate
>).
>
>Please resolve these comments along with any other Last Call comments
>you may receive. Please wait for direction from your document shepherd
>or AD before posting a new version of the draft.
>
>Grüße, Carsten
>---------------------------------
>
>Document: draft-ietf-mboned-64-multicast-address-format-01
>Title: IPv4-Embedded IPv6 Multicast Address Format
>Reviewer: Carsten Bormann
>Review Date: 2012-05-06
>IETF Last Call Date: 2012-04-19
>
>** Summary: This draft is NOT ready for publication as a Proposed
>Standard and should be revised before publication.
>
>The document appears as an attempt to extend the reasoning of RFC 6052
>to multicast IPv4 addresses.  However, while unicast IPv4 addresses
>and their IPv6 counterparts are assigned as part of network
>configuration, multicast addresses are decided upon by applications.
>The document is very short on information how an application should
>decide when to make use of the newly defined formats.  It is therefore
>also hard to understand why these formats are needed in the first
>place.  There appears to be a transition model in the minds of the
>authors that makes this necessary or practical, and this information
>must be made part of the document for it to be useful.

Med: There are plenty of applications using this address format: e.g., [I-D.ietf-softwire-mesh-multicast], [I-D.ietf-softwire-dslite-multicast], [I-D.ietf-softwire-multicast-prefix-option], [I-D.venaas-behave-v4v6mc-framework],  [I-D.sarikaya-behave-netext-nat64-pmip], [I-D.sarikaya-behave-mext-nat64-dsmip], etc. We had pointers to some of those drafts in earlier versions of the document but we removed them and adopted the same approach as RFC6052: only the address format is defined while the usage is defined in companion documents. More details are also documented here: http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.1 and http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.2. 

There is also a problem statement, available at: http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-03 which can be cited in the introduction. 

>
>** Major Issues:
>
>To continue the summary: I don't understand which network elements
>need to be able to determine, by looking at an IP address, that this
>document is in use.  What for?  More generally, which entities need to
>interoperate based on a common understanding of this format?

Med: Elements which make use of the address format are deployment-specific; this can be a receiver, an IPv4-IPv6 PIM interworking function, IGMP/MLD Interworking function. We didn't quoted these interworking functions because this is deployment-specific. Do you think your issue can be solved if we add a pointer to one of the solutions documented listed above?  

>
>Of the various fields left "configurable according to local policies
>of the entity managing the IPv4-IPv6 Interconnection Function", which
>are important for applications?  How do they know these policies?

Med: The content of this filed is left configurable. Its value will depend on the policies enforced by the administrative entity. Examples of these policies are: embedded-RF, use unicast-based prefix, etc. Applications are not aware of these policies since a prefix will (likely /96) will be provisioned (see Section 6).

  If
>that information is all in the two parameters "ASM_MPREFIX64" and
>"SSM_MPREFIX64", what is the protocol that will be used to make this
>information available to applications?  I don't think this can be a
>standards-track document without defining at least one MTI protocol
>for disseminating this information.

Med: The provisioning of the ASM_PREFIX64 and the SSM_PREFIX is orthogonal to the address format itself. Various methods can be used but this is out of scope of the document. We can add a pointer to http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-00 as a provisioning example. Would you be fine with adding such reference?


  What is an implementation
>supposed to do that receives an address that looks like it is governed
>by this document but does not conform to either of the agreed
>prefixes disseminated to the implementation?

Med: This is an issue for the provisioning method and not for the specification of the address format itself.

>
>This document needs editorial attention.  I will abstain from trying
>to make detailed corrections, as this would become tedious quickly.
>While much of this work could be done by the RFC editor, some of the
>editorial decisions will enter e.g. IANA registries, so the technical
>terms need to be decided now.  More importantly, understanding this
>document during its development process (including mine as a reviewer)
>may be hampered by its editorial shortcomings.
>
>** Minor Issues:
>
>My first editorial problem is with the title.  This address format is
>not embedded in IPv4, as the title wants to make us believe.  Instead,
>it is talking about an multicast address format for IPv6 that embeds
>an IPv4 multicast address.  (While this misleading naming repeats the
>same mistake that has been made in RFC 6052, at least there it is not
>part of the title.)

Med: Could you please suggest a better title? 

>
>3
>
>The role of 64IX is very unclear.  My conjecture is that this draft is
>defining the address format for the case M=1 only (i.e., address[16] =
>1).  No text defines what happens for M=0, so the assumption appears
>to be that RFC 4291 applies unchanged in this case.  If this
>conjecture is correct, this needs to be made much clearer.

Med: The current text says: "When "M-bit" is set to 1, it indicates that a multicast
      IPv4 address is embedded in the low-order 32 bits of the multicast
      IPv6 address.". I can add: "When "M-bit" is set to 0, the address format follows [RFC4291].". Would this be fine with you? 

>
>What is "r"?  Define.

Med: This means "reserved". The text says: "All the remaining bits are reserved and MUST be set
      to 0.". Do you think the text should be clarified further? 

>
>4
>
>Why is 64IX moving around here?
>(The discriminating bit M now seems to be address[32].)
>How does one find out which of the two positions of the M bit to use?

Med: Once the prefix is configured to a receiver, an IPv4-IPv6 PIM interworking function, the question of the location of the M-bit is not relevant anymore. If both ASM and SSM modes are supported, two prefixes will be used. 

>
>.          o  sub-group-id: The default value is all zeros.
>How does an application find out when to choose a different one?

Med: Applications are provisioned with the full prefix; see Section 6.

>
>.             232.0.0.1-232.0.0.255 range is being
>.             reserved to IANA.
>Who is making this reservation?  ("is being reserved" means the
>resernation is going on right now, but I don't find anything in 9.)

Med: We removed that sentence as a result of a comment I received from SM (see mboned archives).

>
>7
>
>7 seems to imply this format is only useful where RFC 6052 is in use.
>If this is true, this should be clearly stated.  More specifically,
>the assumption appears to be that all nodes that need to exchange
>information that concerns IPv4 sources need to have the same RFC 6052
>parameters in effect.  How is that ensured?

Med: This is a generic issue for RFC6052. We can document the issue if it is specific to the multicast context. 

>
>** Nits:
>
>10 -- s/defined/defines/

Med: Fixed. Thanks.

>
>(And many more, see above.)
>
>