Subject: [Gen-art] Gen-art last call review of draft-ietf-idr-as-private-reservation-03

From: Elwyn Davies <[email-masked]>
Date: Fri, 15 Feb 2013 10:15:25 +0100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-idr-as-private-reservation-03.txt
Reviewer: Elwyn Davies
Review Date: 15 February 2013
IETF LC End Date: 22 February 2013
IESG Telechat date: (if known) -

Summary: Ready for the IESG.

Nits/editorial comments:  The draft is not actually definitive about 
range of values to be allocated - the range in s10 is just a 
'suggestion'.  Who is actually making the decision about the range?

Aside: I noted that the highest possible 32 bit number (4294967295 = 
0xFFFFFFFF) is excluded from the proposed range.  This is marked as 
reserved in the IANA table but AFAICS this reserved item does not have a 
specification associated with the reservation.  This document would be 
an opportunity to explicitly mention that the topmost value is reserved 
(for future expansion? :-) )

---

From: "Jon Mitchell (GNS)" <[email-masked]>
Date: Mon, 18 Feb 2013 15:26:21 +0000

Elwyn -

Thanks for your review.  The suggestion is being made to IANA who owns the assignment and was discussed at length in the working group with rough consensus.  IANA will replace the suggested values into TBDX values below that text if IESG approves.  This text will not be in the RFC, it's to be stricken from the final document by RFC Editor (I was attempting to write this text in alignment with Section 5.1 of RFC 5226) .

On the final ASN in the range, this is in accordance with like reservation of the existing 2 byte Private ASN reservations, where the final ASN in that space is not utilized either (except for well-known community values).  Also, a case was made that code implementations tend to have issues with final number usage if using incorrect variable types for storage.  That said, the small discussion on and off list about this resolved that if we wanted to formalize the reservation of the last ASN of both the 2 byte space 65535 and the 4 byte space 4294967295, probably a separate draft should be constructed detailing the logic behind these as they have nothing to do with Private ASN's per se and have already been marked as Reserved by IANA as you noted.  I'm open to IESG direction if we want to take a different approach on this...

Cheers,

Jon

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Friday, February 15, 2013 4:15 AM
To: General Area Review Team
Cc: [email-masked]
Subject: Gen-art last call review of draft-ietf-idr-as-private-reservation-03

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

Please resolve these comments along with any other Last Call comments you may receive.

Nits/editorial comments:  The draft is not actually definitive about range of values to be allocated - the range in s10 is just a 'suggestion'.  Who is actually making the decision about the range?

Aside: I noted that the highest possible 32 bit number (4294967295 =
0xFFFFFFFF) is excluded from the proposed range.  This is marked as reserved in the IANA table but AFAICS this reserved item does not have a specification associated with the reservation.  This document would be an opportunity to explicitly mention that the topmost value is reserved (for future expansion? :-) )

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 19 Feb 2013 01:12:05 +0000

On Mon, 2013-02-18 at 15:26 +0000, Jon Mitchell (GNS) wrote:
> Thanks for your review. 
:-)

>  The suggestion is being made to IANA who owns the assignment and was
> discussed at length in the working group with rough consensus.  
As specified in the registry, allocations in this registry are either by
IETF Concensus (i.e. a suitable RFC such as this draft is intended to
be) or request from a RIR. Thus it isn't a matter of suggesting to IANA
but telling them what the IETF want done - so this draft should be
definitive - and what you said about WG concensus constitutes the values
to be used unless somebody else in the IETF manages to alter the
concensus which seems unlikely.
  
> IANA will replace the suggested values into TBDX values below that
> text if IESG approves.  This text will not be in the RFC, it's to be
> stricken from the final document by RFC Editor (I was attempting to
> write this text in alignment with Section 5.1 of RFC 5226) .
Yes, that's fine and as expected.
> 
> On the final ASN in the range, this is in accordance with like
> reservation of the existing 2 byte Private ASN reservations, where the
> final ASN in that space is not utilized either (except for well-known
> community values).  Also, a case was made that code implementations
> tend to have issues with final number usage if using incorrect
> variable types for storage.  That said, the small discussion on and
> off list about this resolved that if we wanted to formalize the
> reservation of the last ASN of both the 2 byte space 65535 and the 4
> byte space 4294967295, probably a separate draft should be constructed
> detailing the logic behind these as they have nothing to do with
> Private ASN's per se and have already been marked as Reserved by IANA
> as you noted.  I'm open to IESG direction if we want to take a
> different approach on this...
Publishing a separate draft seems a bit overkill but clearly that's not
my decision. ;-)

Regards,
Elwyn

---

From: "Jon Mitchell (GNS)" <[email-masked]>
Date: Tue, 19 Feb 2013 20:26:40 +0000

Elwyn -

Yes, I agree this is a reasonable change to remove all of the "suggestion" text in the IANA considerations area and will make sure it is in the next draft if one is required, either way all of that text will be removed by IANA, who has also just sent back their review of the actions required.

On your second comment, currently being published as an RFC is a draft reserving as0 in a similar fashion, so I do think it's most appropriate as a second doc.. and I really have trouble tying these reservations to a RFC about Private ASN's.   If no doc is published, the good news is that IANA has already reserved the last number (with no justification).  Again, if IESG or others feel strongly it should be in this draft, I will try to work out some text to justify their reservations...

Thanks!

Jon

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Monday, February 18, 2013 8:12 PM
To: Jon Mitchell (GNS)
Cc: General Area Review Team; [email-masked]
Subject: RE: Gen-art last call review of draft-ietf-idr-as-private-reservation-03

:-)

> discussed at length in the working group with rough consensus.
As specified in the registry, allocations in this registry are either by IETF Concensus (i.e. a suitable RFC such as this draft is intended to
be) or request from a RIR. Thus it isn't a matter of suggesting to IANA but telling them what the IETF want done - so this draft should be definitive - and what you said about WG concensus constitutes the values to be used unless somebody else in the IETF manages to alter the concensus which seems unlikely.
  
> different approach on this...
Publishing a separate draft seems a bit overkill but clearly that's not my decision. ;-)

Regards,
Elwyn
> reserved in the IANA table but AFAICS this reserved item does not have 
> a specification associated with the reservation.  This document would 
> be an opportunity to explicitly mention that the topmost value is 
> reserved (for future expansion? :-) )
> 
>

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 19 Feb 2013 21:27:49 +0000

Hi, Jon.

On Tue, 2013-02-19 at 20:26 +0000, Jon Mitchell (GNS) wrote:
> Elwyn -
> 
> Yes, I agree this is a reasonable change to remove all of the
> "suggestion" text in the IANA considerations area and will make sure
> it is in the next draft if one is required, either way all of that
> text will be removed by IANA, who has also just sent back their review
> of the actions required.
Seems like we are all agreed where things need to go here. Good!
> 
> On your second comment, currently being published as an RFC is a draft
> reserving as0 in a similar fashion, so I do think it's most
> appropriate as a second doc.. 
Yeh.. I know, I was also gen-art reviewer for that one. Probably too
late to squeeze it in there .. and it wouldn't have been much more
sensible there either.

> and I really have trouble tying these reservations to a RFC about
> Private ASN's.   If no doc is published, the good news is that IANA
> has already reserved the last number (with no justification).  Again,
> if IESG or others feel strongly it should be in this draft, I will try
> to work out some text to justify their reservations...
Oh, well it looks as if somebody ought to spend a merry evening cobbling
together a two section draft to reserve the top number for the sake of
completeness.

Regards,
Elwyn

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Feb 2013 10:29:07 -0500

Jon and Elwyn:

I would like to make a correction here. The WG as a body of experts
suggested to the author via the Author to IANA.  Perhaps as a body of
experts, this WG is sufficient to begin this range.  Second, the suggestion
from the chairs is that IANA might want to allocate a portion of this total
range for initial usage. 

Finally, the Private Address space in the IPV4 space and this IPv6 range are
logically connected, but the numbers are not connected.

Please let me know if this challenges any of your review. 

Sue Hares
(Shepherd and co-chair) 

-----Original Message-----
From: Jon Mitchell (GNS) [mailto:[email-masked]] 
Sent: Monday, February 18, 2013 10:26 AM
To: Elwyn Davies; General Area Review Team
Cc: [email-masked]
Subject: RE: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03

Elwyn -

Thanks for your review.  The suggestion is being made to IANA who owns the
assignment and was discussed at length in the working group with rough
consensus.  IANA will replace the suggested values into TBDX values below
that text if IESG approves.  This text will not be in the RFC, it's to be
stricken from the final document by RFC Editor (I was attempting to write
this text in alignment with Section 5.1 of RFC 5226) .

On the final ASN in the range, this is in accordance with like reservation
of the existing 2 byte Private ASN reservations, where the final ASN in that
space is not utilized either (except for well-known community values).
Also, a case was made that code implementations tend to have issues with
final number usage if using incorrect variable types for storage.  That
said, the small discussion on and off list about this resolved that if we
wanted to formalize the reservation of the last ASN of both the 2 byte space
65535 and the 4 byte space 4294967295, probably a separate draft should be
constructed detailing the logic behind these as they have nothing to do with
Private ASN's per se and have already been marked as Reserved by IANA as you
noted.  I'm open to IESG direction if we want to take a different approach
on this...

Cheers,

Jon

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Friday, February 15, 2013 4:15 AM
To: General Area Review Team
Cc: [email-masked]
Subject: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03

Please resolve these comments along with any other Last Call comments you
may receive.

Nits/editorial comments:  The draft is not actually definitive about range
of values to be allocated - the range in s10 is just a 'suggestion'.  Who is
actually making the decision about the range?

Aside: I noted that the highest possible 32 bit number (4294967295 =
0xFFFFFFFF) is excluded from the proposed range.  This is marked as reserved
in the IANA table but AFAICS this reserved item does not have a
specification associated with the reservation.  This document would be an
opportunity to explicitly mention that the topmost value is reserved (for
future expansion? :-) )

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Feb 2013 10:37:19 -0500

Elwyn and Jon:

This is an IETF consensus about the draft range.  As such, it should be put
in the draft as Jon indicated.  As a shepherd and a co-chair, my comment to
the IANA team is that perhaps they should consider handling out a portion of
the whole space. 

Once it is out, no one ever says "less" but someone always says "more".   I
will try to respond to the IANA or have a conversation about this draft with
them if possible.  I will note this in my status to Stewart Bryant (AD)
today. 

Sue 

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Monday, February 18, 2013 8:12 PM
To: Jon Mitchell (GNS)
Cc: General Area Review Team;
[email-masked]
Subject: RE: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03

:-)

As specified in the registry, allocations in this registry are either by
IETF Concensus (i.e. a suitable RFC such as this draft is intended to
be) or request from a RIR. Thus it isn't a matter of suggesting to IANA but
telling them what the IETF want done - so this draft should be definitive -
and what you said about WG concensus constitutes the values to be used
unless somebody else in the IETF manages to alter the concensus which seems
unlikely.
  
> different approach on this...
Publishing a separate draft seems a bit overkill but clearly that's not my
decision. ;-)

Regards,
Elwyn
may receive.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Feb 2013 10:43:33 -0500

Jon and Elwyn:

These drafts are working toward a larger goal - the eventual update of the
RFC 4271 with current practices.   Getting consensus on these items except
in very small pieces have been extremely difficult. 

Eventually, these will be all rolled up into larger documents that refer to
these smaller documents. 

The reason behind this is tactical. The smaller drafts allow people to stop
doing bad things to BGP immediately.  We have new implementation coming due
to the explosion in the Data center market.  Therefore, vague pieces in
RFC4271 must be plugged now. 

It seems that I really should get around to writing up the process on the
IDR web page and an internet draft. 

Thanks for your hard work, 

Sue 

-----Original Message-----
From: Jon Mitchell (GNS) [mailto:[email-masked]] 
Sent: Tuesday, February 19, 2013 3:27 PM
To: Elwyn Davies
Cc: General Area Review Team;

Elwyn -

Yes, I agree this is a reasonable change to remove all of the "suggestion"
text in the IANA considerations area and will make sure it is in the next
draft if one is required, either way all of that text will be removed by
IANA, who has also just sent back their review of the actions required.

On your second comment, currently being published as an RFC is a draft
reserving as0 in a similar fashion, so I do think it's most appropriate as a
second doc.. and I really have trouble tying these reservations to a RFC
about Private ASN's.   If no doc is published, the good news is that IANA
has already reserved the last number (with no justification).  Again, if
IESG or others feel strongly it should be in this draft, I will try to work
out some text to justify their reservations...

Thanks!

Jon

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]]
Sent: Monday, February 18, 2013 8:12 PM
To: Jon Mitchell (GNS)
Cc: General Area Review Team;

:-)

Regards,
Elwyn
may receive.