[Roll] four minor things with roll-applicability-ami-10.

[Michael Richardson <[e-mail]>]

Hi Nancy, I've done a final review of draft-ietf-roll-applicability-ami-10
as part of the Document Shepherd process, and a few questions came up.
I'm sorry that I didn't catch these during the LC.

0) J.Hui author reference needs to be update, as he's now at Nestlabs.
1) can you update the reference to draft-ietf-roll-terminology to RFC7102.
2) can you add "NOT RECOMMENDED" to the list of 2119 keywords in section 1.1.
3) Does the reference to Experimental RFC: RFC 6997
   ("Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks")
   need to be normative, or would informative suffice?  (It's otherwise a
   hard to explain downref)

4) section 7.2.1 says:

   The maximum IEEE 1901.2 PHY frame payload is 512 bytes.  The maximum
   IEEE 1901.2 MAC frame payload is 1280 bytes, which supports the IPv6
   minimum MTU requirement.

   When there is a mistmatch between the PHY frame payload size and the
   size of a MAC frame carrying an IPv6 packet, IEEE 1901.2 specifies a
   MAC sub-layer segmentation and re-assembly mechanism that provides a
   reliable one-hop transfer of that MAC frame segments.

is this sub-layer always used to get the 1280 bytes needed, or are there
situations where the PHY payload is bigger.  I don't think it matters, but
kind stood out as a sore thumb.

I think that section 7.2.2 means to invoke 6lowpan, but it doesn't do that.
I'm also unclear how 16-bits addresses are assigned in this situation.

In section 7.3.3, rather than a description of IEEE security features, I was
hoping to get an actual list of what would be appropriate in AMI deployments.
"The MAC can be either 4, 8, or 16 bytes long." --- okay, but which one is
being used, and how is this being signaled?

7.3 says:
     However, since the link-layer MTU in both
     wireless and PLC links supports the transmission of a full IPv6
     packet, the use of 6LowPAN fragmentation is NOT RECOMMENDED.

okay, so I think I'm confused.  I agree that 1901.2 and 802.15.4g links
can deal with larger packets, does this spec exclude itself from applying
to 802.15.4 links?  That's okay if that was the intent, I'm just confused
because I thought it included 127-byte 15.4 links.

Given that the document has restricted itself to non-battery powered,
and non-storing mode situations, would a pass through to remove references to
MAYs about battery situations (such as DIOIntervalMin) be appropriate?

I also think that 7.1.2 could be clearer that non-storing is relevant.
I know that the document has sat on the fence for much of it's existence.

I think that section 9.1 is saying that both certificates and session (link)
keys are loaded at the factory.  How would the maker of a new device know
how to turn the link key into something useable by the MAC?  Or
alternatively, how would a utility tell a new manufacturer how they are
managing the link keys?   I'm thinking that a single reference here ought to
suffice, perhaps to some IEEE document section.

sorry to come up with a bunch of nits...

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-