Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

[Job Snijders <[e-mail]>]

On Wed, Oct 05, 2016 at 11:46:06AM -0400, Jeffrey Haas wrote:
> > On Oct 5, 2016, at 11:16 AM, Nick Hilliard <[e-mail]> wrote:
> > 
> > This paragraph should be omitted completely. It adds nothing.
> 
> I agree.

Nick, Jeff, thank you for your feedback. I've deleted the section from
what will be -02.

> To the authors:
> Other things I note while reading the draft:
> "Global Administrator:  A four-octet namespace identifier.  This
> SHOULD be an Autonomous System Number assigned by IANA."
> delete "assigned by IANA".  That's not usually their business.

agreed.

> Similarly, I find the following sentence adds no value:
> "There are no routing semantics implied by the Global Administrator
> field."

This sentence was already deleted following feedback from Tom Petch
(https://mailarchive.ietf.org/arch/msg/idr/GF4yLYbWltrj8rKNtdPk1xxexv8)

Thanks for seconding the removal.

> I am also unclear on the semantics of why atomic aggregate impacts
> whether merging happens or not.  (Please don't make me break out 10+
> year old points as to why AA has been broken from day one.)

I'll leave this for others to comment on.

> I'll reiterate my objection to a mandatory representation format, but
> other implementations that actually are impacted will make my point
> for me.  Unless we're doing a yang module, IETF really has no business
> specifying UI.

There are more examples where the IETF (for better or for worse) has
specified canonical representations. For example, I'd be disappointed if
a major implementation ends up representing Large BGP Communities as
straight uint96_t's in the UI.

A challenge here is that there might be two issues at hand: one is the
canonical way to represent a Large BGP Community in a phone call, or in
technical documentation which is provided by one operator to another
operator. The second issue is what is actually typed/inputted into
network element configurations.

The "Textual Representation" section should provide any implementor with
enough freedom to use a prefix, suffix, or a separator of their
choosing. Given the current text:
https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-ietf-idr-large-community.xml#L208-L232
should we change the first three "MUST" to a "SHOULD" to alleviate your
concern?

Do you consider my concern about a canonical format for inter-operator
communication valid?

> With regard to the security considerations, I'd drop the "and BGP
> Extended Communities".  While the generic ext-comms draft originally
> passed through IETF process with its somewhat weak session, I think
> any practical security analysis of it would point out that the
> signaling information covered by ext-comms is significantly greater
> than the base 1997 case these days.

You make a fair point, I have removed that string (unless someone
champions that it should remain part of the draft).

> Similarly, I'd drop "trust in every other AS in the path" section.  If
> you're going to dig into that issue, you'll end up in a world of
> security considerations hurt.  You still will courtesy of the way our
> security ADs function with their odd understanding of how protocol
> work and operations collide, but you're almost always better off
> starting with too little and let them guide you into what they want to
> see than give them fodder for confusion early on.

To confirm, you propose to change;

	"This document does not change any underlying security issues
	associated with any other BGP Communities mechanism.  Specifically,
	an AS relying on the Large BGP Community attribute carried in BGP
	must have trust in every other AS in the path, as any intermediate
	Autonomous System in the path may have added, deleted or altered
	the Large BGP Community attribute. Specifying the mechanism to
	provide such trust is beyond the scope of this document."

to

	"This document does not change any underlying security issues
    associated with any other BGP Communities mechanism."

correct?

I can agree to this simplification. The text was put in as an attempt to
preempt some security review scrutinity. It continues to be a challenge
to figure out how far one should go to scope expecations, and when to
write down something is out of scope, or not. Feedback from others on
this specific topic is most welcome, if case no further feedback offered
I'll remove that part of the section as per Jeff's recommendation.

Kind regards,

Job