On 12/12/16 1:11 PM, Job Snijders wrote:
Dear Robert,
On Mon, Dec 12, 2016 at 12:43:33PM -0600, Robert Sparks wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair. Please treat these comments just like
any other last call comments.
Thank you for taking the time to review this document!
Document: draft-ietf-idr-large-community-11
Reviewer: Robert Sparks
Review Date: 12 Dec 2016
IETF LC End Date: 16 Dec 2016
IESG Telechat date: 5 Jan 2017
Summary: Ready with nits
First a question (I don't know if this should lead to a change in the
document). You say the use of reserved ASNs is NOT RECOMMENDED and
later that the attribute MUST NOT be considered malformed if it has a
reserved ASN in it. Is it clear what a recipient is supposed to do if
one of these reserved ANSs shows up here? If so (for my own education)
could you point me to where that's described?
If two ASNs agree to exchange Large Communities with each other where
the mutually agreed upon Global Administrator value happens to be a
reserved ASN, that is something for those two networks to decide. The
key point here is that implementations must not impose any restrictions
on the uint32 value in the Global Administrator field. It is entirely at
the operator's discretion what to do with any Large Community, this
applies to reserved and non-reserved values.
The document recommends people to use their globally unique ASN, but
this will not be enforced through implementations.
Thanks for the explanation. It would have avoided the question if the
document said that - consider explicitly adding the key point you point to.
The security section refers to "Network administrators should note the
recommendations in Section 11 of BGP Operations and Security [RFC7454]."
There is some wisdom there to be gleaned.
Nits:
Section 11.3 in the references is only referenced by the implementation
status section which you instruct the rfc-editor to delete. Do you intend
for the reference to also be deleted? If so, save yourself a round-trip with
the RFC-editor and add instructions now. If not, you'll need to find a way
to work a reference in that won't be deleted.
Yes, the intention is that the reference to RFC7942 is to be deleted
before publication.
This is my mistake: I mistook the hyperlink in
https://tools.ietf.org/html/rfc7942#section-2.1 to be a reference, but
its just an automagically converted hyperlink. We'll remove the
reference in the next version.
David Farmer makes a suggestion at
https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s that
looks reasonable to me. Please consider it.
I do not believe there is consensus at this moment to make a blanket
recommendation based on the contents of the registry (whatever they
may be in the future), but rather work with the precise and concise
approach which is currently described.
Jakob Heitz responded to the suggestion to extend the reserved Global
Administrator values, but for some reason I can't find that email in the
IETF IDR archive, I've copy+pasted it here:
-------------
Date: Mon, 05 Dec 2016 03:16:52 +0100
From: "Jakob Heitz (jheitz)" <jheitz@xxxxxxxxx>
To: David Freedman <david.freedman@xxxxxxxxxxxx>
Cc: "idr@xxxxxxxx" <idr@xxxxxxxx>
Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
No new text is required to cover this: 23456 is not an ASN.
Besides, if anyone were to put it into a large community, no harm
would be done other than what would happen if any other unassigned
ASN were used.
About reserving values, we don't reserve values because the values
are unusable, but because we may want to use them for other purposes
later. There is no need to reserve another value. 3 is more than
enough.
Thanks,
Jakob.
--------------
In addition to the above, although the document does not define any
Special-Use BGP Large Communities, the Global Administrator values
specified in Section 2 (0, 65535, 4294967295) could be used if there is
a future need for them. The purpose of recommending that these values
are not to be used is not because there is harm in doing so, but to
leave the door open for future things (should they ever arise). From
this perspective a blanket reservation based on the ASN registry
wouldn't make sense for me.
WFM, but please get your chairs to chase down why the message didn't
make it to the archive.
The security consideration section start out with a sentence that
strongly implies the reader might learn something about the security
considerations for this document by reading RFC1997. That document's
security considerations section says only that "Security issues are
not discussed in this memo."
The reference to RFC 1997 was meant to leverage 20 years of experience
with implementing and operating networks which use RFC 1997 communities.
Well, sure, but where is that 20 years of experience written down for
the next implementer or operator?
The existing pointer essentially has the semantic of "if you need to
know you already know"...
I agree that the security section of RFC 1997 is somewhat sparse, but
the principle still applies: RFC 1997 and Large Communities have similar
security implications, even if they are not properly documented in RFC
1997.
So, I _think_ your intent was to document them here.
I suggest simply deleting this first sentence.
I still think that's the right thing to do.
Please also consider if
there are other BGP documents with substantive security considerations
sections that you can point to instead.
A reference to RFC 7454 is included, I am not aware of other specific
resources that can be pointed at.
Kind regards,
Job