Re: [secdir] secdir review of draft-ietf-mpls-mna-requirements-13

[Adrian Farrel <[e-mail]>]

Hi Dan,

[Speaking as document shepherd]

Many thanks for taking the time to do a review, and for your constructive comments.

The authors may have a different view, but herewith my thoughts.

> I have reviewed draft-ietf-mpls-mna-requirements-13 as part of
> the security directorate's ongoing effort to review all IETF documents
> being processed by the IESG. These comments were written primarily
> for the benefit of the security area directors. Document editors and
> WG chairs should treat these comments just like any other last call
> comments.
>
>   The summary of the review is "Ready with Issues". I wanted to
> say Not Ready since my issue seems important to me but others
> may not see it that way. ADs, take a look.

Fair enough. Anyway, all review comments are taken seriously.

>   The document specifies requirements solutions to use cases that
> specify new operations on MPLS packets. All of the requirements
> seem correct (with the possible exception of one which I'll get to)
> given my general ignorance of MPLS but my issue is that these
> operations are called "Network Actions", which make sense, good
> name, but the the actions to be performed are indicated by
> "Network Action Indicators (NAIs)". These NAIs are to be encoded
> according to RFC 3031, which is the MPLS Architecture document.
> RFC 3031 does not specify an encoding of a thing called an NAI.

Ah, since NAIs are a new thing, you wouldn't find them in RFC 3031.
So, encoded in MPLS *consistent*with* RFC 3031. If the text is not clear about that, we need to change it.

> Unfortunately, RFC 4282 does. It defines a "Network Access
> Identifier" which is technically different than a "Network Action
> Indicator" but I think the naming in this draft unfortunately needs
> to be changed. IESG members who make the decision may disagree
> but I find it confusing to see acronyms redefined like this and
> unfortunately RFC 4282 was there first.

OK. RFC 7542 obsoleted RFC 4282. But your point stands.

Yes, we hadn't noticed the pre-existence  of NAI, and it's re-use is unfortunate, but perhaps not catastrophic since it is used in the context of "MPLS NAI".

The list of abbreviations at https://www.rfc-editor.org/materials/abbrev.expansion.txt is peppered with duplicate expansions, although, to be fair, it does already include Network Access Identifier.

[I did write RFC 5513 to address such problems :-]

There would be quite a lot of editorial work in a number of follow-up documents if we did make a change, so I'd like to punt this to the ADs as the Higher Authority.

>   The requirement I had a problem with was 38: "NAIs MUST be
> allocated through the IANA process specified in the MNA solution
> specification." If you're going to define some thing in a draft
> (even if you give it a new name) and require IANA to allocate them
> then you should have create a registry for these things. Making
> the solution documents allocate their own registries for these
> things seems wrong, IMHO.

Good point. I think this should flip to...
"MNA solution specifications MUST request IANA to create registries and make allocations from those registries for NAIs as necessary to ensure unambiguous identification of NAs."

>   Also, requirement 28 says, "Pint-to-Point (P2P)"-- cheers!--
> should be "Point-to-Point (P2P).

:-)

Cheers (indeed),
Adrian