Subject: [BEHAVE] AD evaluation comments on draft-ietf-behave-address-format-05

From: Magnus Westerlund <[email-masked]>
Date: Sat, 20 Mar 2010 08:04:36 -0700

Authors and WG,

As one of my last acts as AD I have performed an AD review of the
translator documents. As you have seen David is also reviewing the
documents in parallel as preparations for taking over the handling of
these documents. I am very pleased that the WG has managed to progress
these documents without to much delay.

See below my AD comments and questions from this review. As usual please
discuss things with me as it is as likely that I have misunderstood as
there are issues with the document. I also have to state that I have
failed to keep abreast on all the postings on the mailing list.

I do hope that these comments can be addressed quickly and if anyone
needs more discussion that we can identified that prior the IETF week is
over and take it in the BEHAVE session. However, please submit a new
draft as soon as you are able to. It is possible to submit new versions
from Monday of the IETF week.

1. Section 1, first paragraph
I think there should be a reference to RFC 4291 in the introduction to
make it clear where to learn to read IPv6 addresses and the existing
IPv6 address architecture.

2. Section 1:
   This document reserves a "Well-Known Prefix" for use in an
   algorithmic mapping.  The value of this IPv6 prefix is:

      64:FF9B::/96

I get the impression that the prefix is actually defined in the
introducation section. That doesn't seem appropriate.

3. Section 1,
   Section 3 discusses the choice of prefixes, the conditions of use of
   the Well-Known Prefix and Network-Specific Prefixes, and the use of
   IPv4-Embedded IPv6 addresses with stateless and stateful translation.

This springs these concept on the reader. Can some one sentence
explanations be used for the WKP and NSP?

4. Section 2:
It is not clear if it is required to have prefix lengths that are whole
octets or if any bit boundary is allowed. Can this please be clarified.

5. Section 2.1:
   o  If the prefix length is less than 96 bits, remove the last octet
      and insert the null octet "u" at the appropriate position, as
      documented in Figure 1.

"remove the last octet" took some time for me to grasp. It might be
clear if one changes the sentence to:

   o  If the prefix length is less than 96 bits, insert the null octet
"u" at the appropriate position, thus causing the least significant
octet to be excluded, as documented in Figure 1.

6. Section 2.2:
Please update RFC 3330 to RFC 5735.

7. Section 2:

I am missing a subsection defining the well known prefix here. Rather
than having the formal definintion in the introduction this seems to be
a good spot to place that definition.

8. Section 3.3, last paragraph:
uses "SHOULD not" instead of SHOULD NOT.

9. Section 5:

I think it is very appropriate to make it explicit that the WKP is part
of the /8 reserved for IETF it is in. Thus I think this document should
request IANA to assign the prefix out of the IETF block. That way nobody
in the future can forget about this assignment.

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Mar 2010 16:44:43 +0000

Magnus,

I am preparing a revision to take your comments into account.

> IPv6 address architecture.

OK, will add.

> introduction section. That doesn't seem appropriate.

Matter of taste, I believe. The reasoning is that we can just as well be upfront about it. Alternatively, I could add a section "Definition of the Well Known Prefix", with text:

   The value of this IPv6 prefix is:
	      64:FF9B::/96

Not sure that would make the document clearer, but if you prefer, that can certainly be arranged.

> explanations be used for the WKP and NSP?

They used to be defined before, and then we pushed all definitions to a "notation" section. I can certainly move text from the notation section back in the introduction. Or, I could just say

    Section 3 discusses the choice of prefixes, the conditions in which
    they can be used, and the use of IPv4-Embedded IPv6 addresses with 
    stateless and stateful translation.

This would remove the forward reference.

> octets or if any bit boundary is allowed. Can this please be clarified.

Actually, this is defined. The prefixes can only have one of the following lengths: 32, 40, 48, 56, 64 or 96. But I can add a line to restate that.

>       octet to be excluded, as documented in Figure 1.

OK.

> Please update RFC 3330 to RFC 5735.

OK.

> a good spot to place that definition.

OK, will move the intro text to a new section 2.1.

> uses "SHOULD not" instead of SHOULD NOT.

OK.

> in the future can forget about this assignment.

Hum. The theory is that we do not need IANA to assign the prefix, since it is an IETF action. Do you want IANA to "record" the prefix?

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Mar 2010 05:58:56 +1300

> Magnus,

...
> Hum. The theory is that we do not need IANA to assign the prefix, since it is an IETF action. Do you want IANA to "record" the prefix?

Absolutely - IANA does not assign out of ::/8, the IETF does.

By the way, technically this means that the document updates RFC 4291.
This needs to be in the document header at least, and a reference
in the IANA considerations.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 23 Mar 2010 18:05:03 +0100

> Hum. The theory is that we do not need IANA to assign the prefix, since it is an IETF action. Do you want IANA to "record" the prefix?
just talk to Michelle from IANA and she suggested that a good way 
forward would to take a similar approach to RFC 4291, which requests to 
add a note for the 0::/8 assignment in the IPv6 registry that describes 
the purpose of this prefix.

RFC4291 reads:

4.  IANA Considerations

    The "IPv4-Compatible IPv6 address" is deprecated by this document.
    The IANA should continue to list the address block containing these
    addresses at http://www.iana.org/assignments/ipv6-address-space as
    "Reserved by IETF" and not reassign it for any other purpose.  For
    example:

       0000::/8        Reserved by IETF        [RFC3513]      [1]

    The IANA has added the following note and link to this address block.

       [5]  0000::/96 was previously defined as the "IPv4-Compatible IPv6
            address" prefix.  This definition has been deprecated by RFC
            4291.

    The IANA has updated the references for the IPv6 Address Architecture
    in the IANA registries accordingly.

and the registry page can be found at

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

> -- Christian Huitema
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Mar 2010 10:05:20 -0700

Hi Christian,

I have removed the issues where I have no further comment.

> Not sure that would make the document clearer, but if you prefer, that can certainly be arranged.

I do think the document will flow better if the normative definition of
the prefix actually are in Section 2. Having the WKP being stated in the
introduction I think is ok.

> This would remove the forward reference.

The later might be simpler.

> Actually, this is defined. The prefixes can only have one of the following lengths: 32, 40, 48, 56, 64 or 96. But I can add a line to restate that.

Ok, I obviously missed that so restating it is probably good.

> Hum. The theory is that we do not need IANA to assign the prefix, since it is an IETF action. Do you want IANA to "record" the prefix?

Sorry, I used assigned here, when I should have said mark or record.
What I basically want to achieve is that we get a reference to this
document into the table at:
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

If you look at the 0000::/8 you see two references. There should also be
a third one for this document to make it clear that certain part of this
space is used in a particular way.

Cheers

Magnus Westerlund

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Mar 2010 17:26:34 +0000

I think we agree on all proposed updates, but we still need some clarity on the IANA recommendation.

> space is used in a particular way.

So, we would like IANA to add a note to the table, stating something like:

[6] The "Well Known Prefix" used for IPv4 to IPv6 translation is defined out of
    the 0000::/8 address block, per RFC XXXX.

Correct?

-- Christian Huitema

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 23 Mar 2010 10:31:53 -0700

>     the 0000::/8 address block, per RFC XXXX.

with the prefix itself being written in the note I guess.

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Mar 2010 10:33:28 -0700

> with the prefix itself being written in the note I guess.

Yes

-- 

Magnus Westerlund

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Mar 2010 06:44:23 +1300

>> with the prefix itself being written in the note I guess.

And "Updates: 4291" in the document header.

That's important, so that when 4291 is replaced, this change will
not be forgotten.

   Brian

---

From: Xing Li <[email-masked]>
Date: Thu, 25 Mar 2010 01:25:02 +0800

Hi, Christian and All,

Thanks. We agree with your suggestions and updates.

Regards,

xing, congxiao

---

From: Christian Huitema <[email-masked]>
Date: Sat, 27 Mar 2010 19:17:54 +0000

I have applied the changes discussed in this thread, and submitted version 06 of the address draft.

-- Christian Huitema

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Wednesday, March 24, 2010 10:25 AM
To: Christian Huitema
Cc: Magnus Westerlund; Behave WG; [email-masked]; David Harrington
Subject: Re: [BEHAVE] AD evaluation comments on draft-ietf-behave-address-format-05

Hi, Christian and All,

Regards,

xing, congxiao

---

From: Xing Li <[email-masked]>
Date: Mon, 29 Mar 2010 22:33:30 +0800

Hi, Christian,

> I have applied the changes discussed in this thread, and submitted version 06 of the address draft.

Thank you very much.

It seems that the version 06 has not been shown in the IETF website ( 
http://datatracker.ietf.org/wg/behave/ ), could you please kindly upload it?

Regards,

xing

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Mar 2010 16:45:41 +0000

Just realized I forgot to click on the "validate your address" link. Fixed now.

Thanks Xing and Med for reminding me.

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Monday, March 29, 2010 7:34 AM
To: Christian Huitema
Cc: Magnus Westerlund; David Harrington; [email-masked]; Behave WG
Subject: Re: [BEHAVE] AD evaluation comments on draft-ietf-behave-address-format-05

Hi, Christian,

Thank you very much.

Regards,

xing