Subject: [v6ops] Brian Haberman's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT)

From: "Brian Haberman" <[email-masked]>
Date: Wed, 14 Oct 2015 07:31:55 -0700

Brian Haberman has entered the following ballot position for
draft-ietf-v6ops-siit-eam-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have no issues with the publication of this draft, but want to point
out that there an abundance of misuses of 2119 keywords.  Section 3.1
provides useful examples:

   An SIIT implementation MUST include an Explicit Address Mapping Table
   (EAMT).  By default, the EAMT SHOULD be empty.  The operator MUST be
   able to populate the EAMT using the implementation's normal
   configuration interfaces.  The implementation MAY additionally
   support other ways of populating the EAMT.

- How a SIIT implementation manages the mappings has no bearing on the
functionality.  So, saying "MUST include an EAMT" is not needed.

- SHOULD be empty?  At what point? During implementation?

- Why "MUST be able to populate"?

---

From: Tore Anderson <[email-masked]>
Date: Wed, 14 Oct 2015 23:49:08 +0200

Hello Brian,

* Brian Haberman

> out that there an abundance of misuses of 2119 keywords.

If that is an acceptable way forward for you, I am hoping to get help
from the RFC Editor in identifying and improving sorting these out.

> Section 3.1 provides useful examples:
> 

Well, without an EAM Table, there's nowhere to insert EAMs, and thus
you cannot fully implement the draft. It follows logically, therefore,
that an implementation MUST have an EAMT. (This is analogous to the BIB
and Session Tables described in RFC6146.)

That said, perhaps the above goes without saying, and the sentence in
question could be rewritten to drop the "MUST".

> - SHOULD be empty?  At what point? During implementation?

In its default configuration state.

> - Why "MUST be able to populate"?

Because if the operator is unable to populate the EAMT, then the
functionality is pretty much useless. But then again, maybe that goes
without saying too.

Tore

---

From: Brian Haberman <[email-masked]>
Date: Wed, 14 Oct 2015 18:26:36 -0400

Hi Tore,

> from the RFC Editor in identifying and improving sorting these out.

The RFC Editor is not tasked with sorting out the use of 2119 keywords,
so I don't think we can rely on that. That being said, my comments are
non-blocking so please await guidance from Joel and/or the chairs.

> and Session Tables described in RFC6146.)

I can accomplish the same mapping using a Patricia Trie or similar data
structures.

> functionality is pretty much useless. But then again, maybe that goes

I should have continued the quote. Yes, the operator needs to be able to
populate the table. But, that doesn't have to be its "normal"
configuration interface, right?

Yes, some of my comments are a bit pedantic, but I get concerned when
2119 keywords are used when they are not needed.  For example, would
this text work (or something similar) for the first paragraph of 3.1?

A SIIT implementation includes a conceptual table that maps between IPv4
and IPv6 prefixes/addresses. An operator populates the conceptual table
to provide the mappings between the two address families. How the SIIT
implementation provides the interface for adding these mappings is out
of scope for this document.

I will reiterate that this is all non-blocking.

Regards,
Brian

---

From: Tore Anderson <[email-masked]>
Date: Thu, 15 Oct 2015 01:43:46 +0200

Hi again Brian,

* Brian Haberman

> The RFC Editor is not tasked with sorting out the use of 2119
> keywords, so I don't think we can rely on that. That being said, my
> comments are non-blocking so please await guidance from Joel and/or
> the chairs.

Okay. In that case, I would appreciate any suggestions on how to
improve the text. I will readily admit to not having much experience in
writing formal and "pedantically correct" I-D texts.

In any case, I'm very happy to let Joel/Fred/Lee decide on how to
proceed.

> >>    An SIIT implementation MUST include an Explicit Address Mapping
> >> Table (EAMT).  By default, the EAMT SHOULD be empty.  The operator
> >> MUST be able to populate the EAMT using the implementation's normal
> >> - How a SIIT implementation manages the mappings has no bearing on
> >> the functionality.  So, saying "MUST include an EAMT" is not
> >> needed.
> > 
> > you cannot fully implement the draft. It follows logically,
> > therefore, that an implementation MUST have an EAMT. (This is
> > analogous to the BIB and Session Tables described in RFC6146.)
> 
> I can accomplish the same mapping using a Patricia Trie or similar
> data structures.

Ah, I see our disconnect now. The text doesn't (read: isn't meant to)
mandate any particular way on how exactly the EAMT is stored and looked
up in "under the hood". So you're absolutely free to store the EAMT in
a trie or a linked list or whatever you want - as long as it looks like
a table to the operator, you'd be within spec.

An analogous concept would be an IP routing table.

> > functionality is pretty much useless. But then again, maybe that
> > goes without saying too.
> 
> I should have continued the quote. Yes, the operator needs to be able
> to populate the table. But, that doesn't have to be its "normal"

Well, if I bought a router that's normally managed through an SSH
command line interface I'd be rather annoyed if the EAMT could not be
maintained through that interface.

But then again, it probably goes without saying.

> A SIIT implementation includes a conceptual table that maps between
> IPv4 and IPv6 prefixes/addresses. An operator populates the
> conceptual table to provide the mappings between the two address
> families. How the SIIT implementation provides the interface for
> adding these mappings is out of scope for this document.

Absolutely. I'll probably rewrite it to use the precise defined terms
(e.g., "EAM" rather than "mapping"), but as far as the lack of RFC2119
keywords go this text is completely fine with me.

Tore