Transmission of IPv6 Packets over Near Field Communication
draft-ietf-6lo-nfc-22

[Ballot comment]
Thanks for addressing my DISCUSS feedback.

** Section 3.4.  Most of these normative statement appear to be restatements of Section 4.5.2 of NFC Forum’s LLCP version 1.4.  The style of this document seems to be specifying behavior that is in fact already specified authoritatively elsewhere.

** Section 7.
  Ad-hoc secure data transfer can be established between two
  communication parties without any prior knowledge of the
  communication partner.  Ad-hoc secure data transfer can be vulnerable
  to Man-In-The-Middle (MITM) attacks.  Authenticated secure data
  transfer provides protection against Man-In-The-Middle (MITM)
  attacks.  In the initial bonding step, the two communicating parties
  store a shared secret along with a Bonding Identifier.  For all
  subsequent interactions, the communicating parties re-use the shared
  secret and compute only the unique encryption key for that session.
  Secure data transfer is based on the cryptographic algorithms defined
  in the NFC Authentication Protocol (NAP).

-- This entire text is cut-and-paste from Section 3.2.5 of NFC Forum LLC.  Given that this text is used verbatim shouldn’t it be cited?

-- If the text is going to be restated, in the spirit of inclusive language, please consider alternative language to “MiTM”.

[Ballot discuss]
Thanks for working on this specification. Thanks to Wesley Eddy for his excellent TSVART review.

As I agree with the points brought up by the TAVART reviewer, I would like to discuss why the points made by the reviewer should not be considered for this specification.

[Ballot discuss]
(revised)

Multiple DISCUSes were filed during the March 2019 telechat on the basis of concerns that the underlying normative references were not available.  In response, the "NFC LLC v1.4" specification was shared in advance of the December 2022 telechat. However, it appears additional normative references are needed to evaluate the security claims of the protocol (NFC LLC v1.4).

Section 7.1 of NFC LLC v1.4 says:

Secure data transfer uses the NFC Authentication Protocol [NAP]. This subsection defines three processes: Security Setup, Bonding Process and Authentication Process. All three processes are mappings of the corresponding processes with the same names defined in [NAP].

Section 7 of this I-D says:

  Ad-hoc secure data transfer can be established between two
  communication parties without any prior knowledge of the
  communication partner.  Ad-hoc secure data transfer can be vulnerable
  to Man-In-The-Middle (MITM) attacks.  Authenticated secure data
  transfer provides protection against Man-In-The-Middle (MITM)
  attacks.  In the initial bonding step, the two communicating parties
  store a shared secret along with a Bonding Identifier.  For all
  subsequent interactions, the communicating parties re-use the shared
  secret and compute only the unique encryption key for that session.
  Secure data transfer is based on the cryptographic algorithms defined
  in the NFC Authentication Protocol (NAP).

The described security properties appear to depend on the “NFC Authentication Protocol” (NAP) which is neither formally referenced with a normative reference (like the NFC LLC v1.4 specification) and does not appear to be available.  It is challenging to evaluate the security claims without it.

Thank you to the document authors for responding to a preliminary version of this DISCUSS position which said that it is not possible to share the NAP specification. See https://mailarchive.ietf.org/arch/msg/6lo/ii9ANOvsJKr08kr7oOCWQ635GtI/.  If the specification is not available, it isn’t clear how the IETF consensus review process is possible.  The shepherd write-up says “Access to the NFC spec has been available for those that have needed it.”

[Ballot comment]
** Section 1.  Editorial.
As of the writing, NFC is supported
  by the main smartphone operating systems.

In what way is this germane?  Will this text age well?

** Section 3.4.  Most of these normative statement appear to be restatements of Section 4.5.2 of NFC Forum’s LLCP version 1.4.  The style of this document seems to be specifying behavior that is in fact already specified authoritatively elsewhere.

** Section 4.2.  Per the use of RFC713 to generate the interface identifiers, is there any guidance to provide on:

-- which hash function is to be used for F()

-- how to generate the Network_ID

-- generating the secret_key

** Section 4.2.  Editorial. What is Figure 4 showing that isn’t already stated in the previous sentence of “interface identifiers of all unicast addresses for NFC-enabled devices are 64 bits long and constructed by using the generation algorithm of random (but stable)    identifier (RID)”

** Section 7.
  Ad-hoc secure data transfer can be established between two
  communication parties without any prior knowledge of the
  communication partner.  Ad-hoc secure data transfer can be vulnerable
  to Man-In-The-Middle (MITM) attacks.  Authenticated secure data
  transfer provides protection against Man-In-The-Middle (MITM)
  attacks.  In the initial bonding step, the two communicating parties
  store a shared secret along with a Bonding Identifier.  For all
  subsequent interactions, the communicating parties re-use the shared
  secret and compute only the unique encryption key for that session.
  Secure data transfer is based on the cryptographic algorithms defined
  in the NFC Authentication Protocol (NAP).

-- This entire text is cut-and-paste from Section 3.2.5 of NFC Forum LLC.  Given that this text is used verbatim shouldn’t it be cited?

-- If the text is going to be restated, in the spirit of inclusive language, please consider alternative language to “MiTM”.

[Ballot discuss]
(Preliminary ballot from an incomplete review of the document, but shared here for early awareness)

Multiple prior DISCUSes were filed on the basis of concerns that the base normative references were not available.  In response, the "NFC LLC v1.4" specification was shared. However, it appears additional normative references are needed to evaluate the security claims of the protocol (NFC LLC v1.4).

Section 7 of this I-D says:

  Ad-hoc secure data transfer can be established between two
  communication parties without any prior knowledge of the
  communication partner.  Ad-hoc secure data transfer can be vulnerable
  to Man-In-The-Middle (MITM) attacks.  Authenticated secure data
  transfer provides protection against Man-In-The-Middle (MITM)
  attacks.  In the initial bonding step, the two communicating parties
  store a shared secret along with a Bonding Identifier.  For all
  subsequent interactions, the communicating parties re-use the shared
  secret and compute only the unique encryption key for that session.
  Secure data transfer is based on the cryptographic algorithms defined
  in the NFC Authentication Protocol (NAP).

This text is a cut-and-paste verbatim from Section 3.2.5 of NFC Forum LLC specification previously shared as part of the last telechat.  However the NAP is defined in yet another NFC Forum document.  How does one access that?

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-6lo-nfc-19
CC @jgscudder

(Updated December 14 -- thanks to the authors for sharing the base spec. I'll re-do my review using it, but need more time, so I am hitting DEFER.)

This document seems promising and needed, but as noted below, I think it still needs work before it should advance. I support Lars's DISCUSS -- as noted below, lack of the foundational Normative reference prevented me from being able to complete a meaningful review of this document. I notice this point was raised in a DISCUSS by Eric Rescorla in 2019, I'm surprised it hasn't been addressed. I do see in the shepherd write-up that "Access to the NFC spec has been available for those that have needed it" but regrettably, it's not clear how this is accomplished.

## COMMENTS

### General

I agree with Warren's observation that "it doesn't seem like [the document] contains enough information to allow a full implementation". Addressing the specific comments below would be helpful, but not sufficient to address that concern, but lacking the [LLCP-1.4] spec it's difficult to be more specific. Because I feel unable to properly evaluate the document's fitness, I'm balloting ABSTAIN.

The shepherd write-up tells us that "An implementation of 6lo-NFC exists and they participated on a 6lo plugtests". I can only guess that the implementors benefit from being experts who know what to read between the lines, whereas reviewers such as myself can read only what's written in the document.

### Section 3.2, remove "such as"

"The LLC contains three components, such as Link Management, Connection-oriented Transmission, and Connectionless Transmission."

The "such as" seems wrong here. I guess you mean "namely", or you could just remove "such as" and not replace it with anything.

### Section 3.4, "transported to an I PDU"

"As mentioned in Section 3.2, when an IPv6 packet is transmitted, the packet MUST be passed down to LLCP of NFC and transported to an I PDU of LLCP of the NFC-enabled peer device."

Do you mean "... and transported in an I PDU of LLCP *to* the NFC-enabled peer device"?

### Section 3.4, mystery bits 1011

Figure 2 shows a field, labeled "1011", occupying bits 16 through 21. It's not clear what this means. It's not discussed in the text. One might imagine it's just a field value mandated by [LLCP-1.4], but in that case one would imagine it would depict a 6-bit string, since the field it's occupying is six bits. What is going on there? I would refer to [LLCP-1.4] to try to find out, but as mentioned, it isn't available for review.

What's more, the labeling appears to conflict with the text that says "the unused bits in the TLV Value field MUST be set to zero".

### Section 3.4, how to fit eleven bits into a ten bit field

Still in Figure 2, we see the rightmost field labeled 0x0~0x7FF, and the paragraph following agrees that the field "MUST be encoded into the least significant 11 bits". But the ruler at the top shows the field extending from bit 22 to bit 31, a field of only 10 bits.

My guess is you drew the ruler wrong, and it was supposed to start at bit 21? But that would still leave the previous "1011" question open.

### Section 3.4, MUST be 0x480

"The MIUX value MUST be 0x480 to support the IPv6 MTU requirement (of 1280 bytes)" unambiguously mandates that MIUX must be exactly 0x480, no more and no less. I understand the "no less" part, as noted in the quote this is needed to support a 1280 byte MTU. However, IPv6 doesn't forbid offering a larger value than 1280.

I'm guessing you left out an "at least", as in "MUST be at least 0x480". If you really intend to mandate that packets shall be no larger than 1280, please say why?

### Section 4.3 et seq, 6LBR, 6LR, 6LM

Please expand 6LBR, 6LR, 6LM on first use.

### Section 4.4, bullet 2 is hard to understand

I gave up trying to understand what this bullet means, I'm afraid I can't even hazard a guess at a rewrite. :-(

## NITS

### Section 7

"(i.e., ad-hoc mode and authenticated mode"
                                          ^ does the missing closing parenthesis go here?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# GEN AD review of draft-ietf-6lo-nfc-19

CC @larseggert

## Comments

Thanks for making the LLCP-1.4 spec available to the IESG.

### Section 3.4, paragraph 7
```
    When the MIUX parameter is used, the TLV Type field MUST be 0x02 and
    the TLV Length field MUST be 0x02.  The MIUX parameter MUST be
    encoded into the least significant 11 bits of the TLV Value field.
    The unused bits in the TLV Value field MUST be set to zero by the
    sender and ignored by the receiver.
```
Figure 2 shows that the V field is split into 4 bits and 12 bits, not
11? Also, the four bits are not zero?

### DOWNREFs

DOWNREF `[RFC3756]` from this Proposed Standard to Informational `RFC3756`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `man`; alternatives might be `individual`, `people`, `person`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.1, paragraph 1
```
-    is used for IPv6 over NFC.
-    ^^
+    MUST be used for IPv6 over NFC.
+    ^^^^^^^
```

### Outdated references

Reference `[RFC3633]` to `RFC3633`, which was obsoleted by `RFC8415` (this may
be on purpose).

### Grammar/style

#### Section 4.2, paragraph 4
```
pology. NFC supports mesh topologies but most of all applications would use a
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
I share other ADs' concern about availability of the NFC spec, however it is my understanding that Erik has had access to it, and I trust he was able to do a full review of the draft.

Given that, I would ballot No Objection. However I have identified what I think is a simple typo, but important enough to warrant a blocking comment. Section 4.8:

> Length:
>
> This is the length of this option (including the type and length fields) in units of 8 octets. The value of this field is 1 for 6-bit NFC node addresses.

I believe you meant "in octets" or "in units of 8 bits", right?

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-6lo-nfc-19
CC @jgscudder

This document seems promising and needed, but as noted below, I think it still needs work before it should advance. I support Lars's DISCUSS -- as noted below, lack of the foundational Normative reference prevented me from being able to complete a meaningful review of this document. I notice this point was raised in a DISCUSS by Eric Rescorla in 2019, I'm surprised it hasn't been addressed. I do see in the shepherd write-up that "Access to the NFC spec has been available for those that have needed it" but regrettably, it's not clear how this is accomplished.

## COMMENTS

### General

I agree with Warren's observation that "it doesn't seem like [the document] contains enough information to allow a full implementation". Addressing the specific comments below would be helpful, but not sufficient to address that concern, but lacking the [LLCP-1.4] spec it's difficult to be more specific. Because I feel unable to properly evaluate the document's fitness, I'm balloting ABSTAIN.

The shepherd write-up tells us that "An implementation of 6lo-NFC exists and they participated on a 6lo plugtests". I can only guess that the implementors benefit from being experts who know what to read between the lines, whereas reviewers such as myself can read only what's written in the document.

### Section 3.2, remove "such as"

"The LLC contains three components, such as Link Management, Connection-oriented Transmission, and Connectionless Transmission."

The "such as" seems wrong here. I guess you mean "namely", or you could just remove "such as" and not replace it with anything.

### Section 3.4, "transported to an I PDU"

"As mentioned in Section 3.2, when an IPv6 packet is transmitted, the packet MUST be passed down to LLCP of NFC and transported to an I PDU of LLCP of the NFC-enabled peer device."

Do you mean "... and transported in an I PDU of LLCP *to* the NFC-enabled peer device"?

### Section 3.4, mystery bits 1011

Figure 2 shows a field, labeled "1011", occupying bits 16 through 21. It's not clear what this means. It's not discussed in the text. One might imagine it's just a field value mandated by [LLCP-1.4], but in that case one would imagine it would depict a 6-bit string, since the field it's occupying is six bits. What is going on there? I would refer to [LLCP-1.4] to try to find out, but as mentioned, it isn't available for review.

What's more, the labeling appears to conflict with the text that says "the unused bits in the TLV Value field MUST be set to zero".

### Section 3.4, how to fit eleven bits into a ten bit field

Still in Figure 2, we see the rightmost field labeled 0x0~0x7FF, and the paragraph following agrees that the field "MUST be encoded into the least significant 11 bits". But the ruler at the top shows the field extending from bit 22 to bit 31, a field of only 10 bits.

My guess is you drew the ruler wrong, and it was supposed to start at bit 21? But that would still leave the previous "1011" question open.

### Section 3.4, MUST be 0x480

"The MIUX value MUST be 0x480 to support the IPv6 MTU requirement (of 1280 bytes)" unambiguously mandates that MIUX must be exactly 0x480, no more and no less. I understand the "no less" part, as noted in the quote this is needed to support a 1280 byte MTU. However, IPv6 doesn't forbid offering a larger value than 1280.

I'm guessing you left out an "at least", as in "MUST be at least 0x480". If you really intend to mandate that packets shall be no larger than 1280, please say why?

### Section 4.3 et seq, 6LBR, 6LR, 6LM

Please expand 6LBR, 6LR, 6LM on first use.

### Section 4.4, bullet 2 is hard to understand

I gave up trying to understand what this bullet means, I'm afraid I can't even hazard a guess at a rewrite. :-(

## NITS

### Section 7

"(i.e., ad-hoc mode and authenticated mode"
                                          ^ does the missing closing parenthesis go here?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
# GEN AD review of draft-ietf-6lo-nfc-19

CC @larseggert

## Discuss

### Section 9, paragraph 2
```
    [LLCP-1.4] "NFC Logical Link Control Protocol, Version 1.4", NFC
                Forum Technical Specification , January 2021.
```
Eric raised this for -13 in 2019 already: this specification does not
seem to be publicly available? Did the NFC forum share a copy with
the IETF WG that you could forward to the IESG for our review?

[Ballot comment]
## Comments

### Section 3.4, paragraph 7
```
    When the MIUX parameter is used, the TLV Type field MUST be 0x02 and
    the TLV Length field MUST be 0x02.  The MIUX parameter MUST be
    encoded into the least significant 11 bits of the TLV Value field.
    The unused bits in the TLV Value field MUST be set to zero by the
    sender and ignored by the receiver.
```
Figure 2 shows that the V field is split into 4 bits and 12 bits, not
11? Also, the four bits are not zero?

### DOWNREFs

DOWNREF `[RFC3756]` from this Proposed Standard to Informational `RFC3756`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `man`; alternatives might be `individual`, `people`, `person`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.1, paragraph 1
```
-    is used for IPv6 over NFC.
-    ^^
+    MUST be used for IPv6 over NFC.
+    ^^^^^^^
```

### Outdated references

Reference `[RFC3633]` to `RFC3633`, which was obsoleted by `RFC8415` (this may
be on purpose).

### Grammar/style

#### Section 4.2, paragraph 4
```
pology. NFC supports mesh topologies but most of all applications would use a
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-6lo-nfc-19
CC @evyncke

Thank you for the work put into this document. It could indeed be useful and it would deserve a high quality specification.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Carles Gomez for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. But, the write-up is incorrect about the downward reference as https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ indicates RFC 3756 is a downref...

Please note that Pascal Thubert is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Pascal will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/reviewrequest/16761/

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Tagging of references

I have not checked all references, but at least RFC 3633 should not be normative but only informative.

Moreover, RFC3633 is obsoleted by RFC 8415 for 4 years.

### Section 3.4

As far as I understand the document and its relationship with NFC standards, then it is not up to the IETF to use normative language around MIUX (specified by NFC), so, the "MUST" below should rather be "is".
```
  When the MIUX parameter is used, the TLV Type field MUST be 0x02 and
  the TLV Length field MUST be 0x02.  The MIUX parameter MUST be
  encoded into the least significant 11 bits of the TLV Value field.
  The unused bits in the TLV Value field MUST be set to zero by the
  sender and ignored by the receiver.
```

The "MUST" in `The MIUX value MUST be 0x480 to support the IPv6 MTU requirement (of 1280 bytes).` is of course fine.

Finally, please add a normative reference to RFC 8200.

### Section 4.2

Is this section normative ? There is no BCP14 words in it.

If normative, then how is Network_ID derived from any NFC parameter?

### Section 4.3

While not really a DISCUSS point, what is the link between DHCP-PD and a LLA ? Remove the part about getting a prefix.

What is a `secured and stable IID` ? Do the authors mean a 'random and stable IID'?

### Section 4.4 and 5

In section 4.4: `NFC supports mesh topologies but ...`

In section 5: `An NFC link does not support a star topology or mesh network topology`

So, is mesh supported or not ?

### Section 4.5

Is this section normative ? There is no BCP14 terms.

Is there a IANA registry for "Dispatch" values ? If so, then please add a reference. It *seems* that the length is 1 octet, please specify the length of the value.

### Section 4.6

Possibly due to my ignorance of RFC 6282, but this document refers to TCP (section 4.1) while RFC 6282 only compresses UDP ?

Is `6-bit NFC link-layer` the same as the `6-bit SSAP` discussed before ? I guess so but I should not guess but be sure.

### Section 4.8

Is this section normative about multicast replication ?

### Section 5.1

```
  Two or more 6LNs may be connected with a 6LBR, but each connection
  uses a different subnet.
```
Unsure whether 'subnet' means 'IPv6 prefix' or 'link' ?

`the 6LBR MUST ensure address collisions do not occur` how can this goal be achieved.

[Ballot comment]

## COMMENTS

### Shepherd write-up

The write-up is incorrect about the downward reference as https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ indicates RFC 3756 is a downref... Unsure whether this reference to RFC 3756 should be normative though.

### IEEE 802.15.4

Should there be an informative reference to IEEE Std 802.15.4 ?

### Section 1

`NFC is often regarded as a secure communications technology, due to its very short transmission range.` More explanations or even a reference would be welcome.

### Section 3.2

Should 'reliable' be qualified ? E.g., does it mean no packet loss ?

```
  The LLCP to IPv6 protocol
  binding MUST transfer the Source Service Access Point (SSAP) and
  Destination Service Access Point (DSAP) value to the IPv6 over NFC
  protocol.
```
Should this be "to the IPv6 over NFS adaptation later" ?

### Section 4.4

There is text for "For sending Router Solicitations and processing Router Advertisements" but what about "receiving RS and sending RA" ?

## NITS

### kbit/s or kbps

Select one unit and keep using it rather than changing during the document.

### Hexadecimal presentation

Most IETF drafts use 0x3f rather than 3Fh (really cosmetic). Section 3.4 uses 0x02. Suggest to be consistent.

### Section 4.2

I do not see the value of figure 2. Consider removing it.

### Section 4.3

Please use RFC 5952 for IPv6 address format.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational,
Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in
the title page header?

A. draft-ietf-6lo-nfc-18 draft is a 'standards track' document. The intended status is indicated
in the document header. Since it is defining ipv6-over NFC adaptation layer, it is standard track.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a
Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  Near field communication (NFC) is a set of standards for smartphones
  and portable devices to establish radio communication with each other
  by touching them together or bringing them into proximity, usually no
  more than 10 cm. The NFC technology has been widely implemented and available
  in mobile phones, laptop computers, and many other devices.  This
  document describes how IPv6 is transmitted over NFC using 6LowPAN
  techniques.

  Considering the potential for exponential growth in the number of
  heterogeneous air interface technologies, NFC would be widely used as
  one of the other air interface technologies, such as Bluetooth Low
  Energy (BT-LE), Wi-Fi, and so on.  Each of the heterogeneous air
  interface technologies has its own characteristics, which cannot be
  covered by the other technologies, so various kinds of air interface
  technologies would co-exist together.  Therefore, it is required for
  them to communicate with each other. Running IPv6 over the various low
  power L2 technologies with the modified 6lowpan stack ensures interoperability
  among the devices with various heterogeneous air interfaces.




Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular
points or were there decisions where the consensus was particularly rough?

A. This document has been revised several times based on working group comments. It has been reviewed by
  several experienced 6lo working group members including Pascal Thubert and Dave Thaler  who have been
  designated reviewers of this document. It has has also received shepherd's comments and went through two
  WGLC ( one short and one regular one).

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their
plan to implement the specification? Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?
In the case of a Media Type review, on what date was the request posted?

A.

The document has been reviewed and discussed by many 6lo experts in the WG including Pascal Thubert, Carsten Bormann,
Dave Thaler, Samita Chakrabarti, Gabriel Montenegro, James Woodyatt, Alex Petrescue, Michael Richardson.

An implementation of 6lo-NFC exists and they participated on a 6lo plugtests.
The document effort is also socialized with NFC-Forum and they are well aware this document.
Access to the NFC spec has been available for those that have needed it.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd: Carles Gomez, Responsible Area Director: Suresh Krishnan


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version
of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A. This document has had two document shepherds. Samita Chakrabarti reviewed the -09 version of the document and provided comments. She considered that the -10 version of 6lo-nfc document was ready for publication. The IESG evaluated version -13 of the document. At that moment, a new, and the current shepherd (Carles Gomez) was assigned to the document. After the IESG evaluation, the draft was updated several times, in order to address the IESG comments. The current shepherd participated actively in a major (mostly editorial) rewrite of the document, leading to version -17 of the document. The current shepherd considered that -17 was ready for publication. (Note that, as of the last update of this writeup, a subsequent draft revision, i.e. -18 has been produced in order to address a comment by the AD, Erik Kline, regarding security.)



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been
performed?

A. The document is ready for IESG review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took
place.

A. Not applicable.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the
Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail
those concerns here.

A.  It has been reviewed by a number of WG members and by the former and the current shepherd. It is ready to advance.




(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with
the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

A. An IPR Disclosure has been filed and recorded in IETF page
  https://datatracker.ietf.org/ipr/2653/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and
conclusion regarding the IPR disclosures.
A. Yes. There is no objection at the WG about the IPR filed for the document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the WG as a whole understand and agree with it?

A. The working group as a whole understands and agrees with the progress of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the
areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate
email because this questionnaire is publicly available.)

A. No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough;
this check needs to be thorough.

No issues found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type,
and URI type reviews.

A. Not Applicable.

(13) Have all references within this document been identified as either normative or informative?

A. Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an
unclear state? If such normative references exist, what is the plan for their completion?
A. No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references
to support the Area Director in the Last Call procedure.

A. None.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the
title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the document where the relationship of
this document to the other RFCs is discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No. This document will not update any base 6lo documents or existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to
its consistency with the body of the document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A. The document does not request any IANA change.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public
guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A. Not Applicable

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.(1) What type of
RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

A. Not Applicable

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational,
Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in
the title page header?

A. draft-ietf-6lo-nfc-10 draft is a 'standards track' document. The intended status is indicated
in the document header. Since it is defining ipv6-over NFC adaptation layer, it is standard track.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a
Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  Near field communication (NFC) is a set of standards for smartphones
  and portable devices to establish radio communication with each other
  by touching them together or bringing them into proximity, usually no
  more than 10 cm. The NFC technology has been widely implemented and available
  in mobile phones, laptop computers, and many other devices.  This
  document describes how IPv6 is transmitted over NFC using 6LowPAN
  techniques.

  Considering the potential for exponential growth in the number of
  heterogeneous air interface technologies, NFC would be widely used as
  one of the other air interface technologies, such as Bluetooth Low
  Energy (BT-LE), Wi-Fi, and so on.  Each of the heterogeneous air
  interface technologies has its own characteristics, which cannot be
  covered by the other technologies, so various kinds of air interface
  technologies would co-exist together.  Therefore, it is required for
  them to communicate with each other. Running IPv6 over the various low
  power L2 technologies with the modified 6lowpan stack ensures interoperability
  among the devices with various heterogeneous air interfaces.




Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular
points or were there decisions where the consensus was particularly rough?

A. This document has been revised several times based on working group comments. It has been reviewed by
  several experienced 6lo working group members including Pascal Thubert and Dave Thaler  who have been
  designated reviewers of this document. It has has also received shepherd's comments and went through two
  WGLC ( one short and one regular one).

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their
plan to implement the specification? Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?
In the case of a Media Type review, on what date was the request posted?

A.

The document has been reviewed and discussed by many 6lo experts in the WG including Pascal Thubert, Carsten Bormann,
Dave Thaler, Samita Chakrabarti, Gabriel Montenegro, James Woodyatt, Alex Petrescue, Michael Richardson.

An implementation of 6lo-NFC exists and they participated on a 6lo plugtests.
The document effort is also socialized with NFC-Forum and they are well aware this document.
Access to the NFC spec has been available for those that have needed it.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd: Carles Gomez, Responsible Area Director: Suresh Krishnan


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version
of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A. Document shepherd has reviewed the -09 version of the document and provided comments. The -10
  version of 6lo-nfc document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been
performed?

A. The document is ready for IESG review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took
place.

A. Not applicable.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the
Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail
those concerns here.

A.  It has been reviewed by a number of WG members and the shepherd. It is ready to advance.




(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with
the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

A. An IPR Disclosure has been filed and recorded in IETF page
  https://datatracker.ietf.org/ipr/2653/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and
conclusion regarding the IPR disclosures.
A. Yes. There is no objection at the WG about the IPR filed for the document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the WG as a whole understand and agree with it?

A. The working group as a whole understands and agrees with the progress of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the
areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate
email because this questionnaire is publicly available.)

A. No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough;
this check needs to be thorough.

No issues found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type,
and URI type reviews.

A. Not Applicable.

(13) Have all references within this document been identified as either normative or informative?

A. Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an
unclear state? If such normative references exist, what is the plan for their completion?
A. No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references
to support the Area Director in the Last Call procedure.

A. None.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the
title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the document where the relationship of
this document to the other RFCs is discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No. This document will not update any base 6lo documents or  existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to
its consistency with the body of the document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A. The document does not request any IANA change.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public
guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A. Not Applicable

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.(1) What type of
RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

A. Not Applicable

[Ballot discuss]
I attempted to review the changes from -13 to -17, as well as look at
the -17 in isolation, though I do not really have enough time available
to do a proper review before my term as AD expires.

I'm still worried that in general this document doesn't give a clear
picture of how all the pieces fit together, and which pieces are new
as opposed to reused from other specifications.

I do appreciate many of the updates made to streamline the introductory
text and keep it focused on what is relevant for this document.

I am also happy to see that use of MIUX has been made mandatory so that
the L2CAP FAR is not needed.  However, I do not see much justification
for the MUST-level requirement that the MIUX value be exactly 0x480.
Is there some reason to forbid the negotiation of larger link MTU, if
both parties are capable?  I would have expected only a requirement
that the MIUX value be at least 0x480.

Section 4.3 should probably provide some guidance on choosing the PRF
F().  We are implicitly relying on RFC 7217 for a lot of things, some of
which 7127 doesn't even cover, and the suggested construction in RFC
7127 may not still be best practice.

I think the figure in Section 3.4 that lays out the encoding of the
MIUX TLV is incomplete or inaccurate -- e.g., the third field shows
only four bits but the labels indicate it should occupy six bits,
and the range of values for the fourth field indicates it should occupy
eleven bits but the column labels give it only ten.

A section-by-section point as well:

Section 4.5

  o  When an NFC-enabled 6LN is directly connected to a an NFC-enabled
      6LBR, the NFC 6LN MUST register its address with the 6LBR by

How does the device know that it's talking NFC to a 6LBR as opposed to
some non-border-router peer?

[Ballot comment]
Section 4.1

It's unclear to me what information I'm supposed to get from Figure 3
that differs from what was in Figure 1.

Section 4.2

The writing here is hard to follow -- I'm supposed to utilize the 6-bit
NFC LLCP address to form an IID (with nothing about how), but then we
see that IIDs for unicast are randomly generated (without using the LLCP
address), and only finally at the end do we mention the RFC 7217 PRF
(and not even by name!)

Section 4.4

  o  When two or more NFC devices are connected, there are two cases.
      One is that three or more NFC devices are linked with multi-hop
      connections, and the other is that they meet within a single hop
      range.  [...]

I thought we said that NFC was a two-party thing only.  How are we
getting multi-hop connections?  If I assume that this is talking about
the IPv6 layer, how do we guarantee that only NFC-capable devices are
participating in the IPv6 network?

Section 4.8

A note that the field descriptions are largely copied from Section 4.6.1
of RFC 4861 would still be helpful.

Section 7

I think it would be good to retain the paragraph about mitigating the
threat of correlation of activities over time that was removed between
-13 and -17; it would just be better for it to appear later in the
section.

[Ballot comment]
Thanks for addressing my DISCUSS points. Original COMMENT below:

= General =

I agree with Benjamin that the marketing-type language in the document should be removed.

I wonder about the claims of security based on proximity in this document. Presumably attacks in which users are induced to tap their device against another node or terminal which has been compromised by an attacker are becoming more common as NFC becomes more common; adding IPV6 connectivity to the terminal stack surely broadens the potential damage done in such a case. This seems worth noting.

= Section 1 =

OLD
It has been used in devices such as mobile phones, running Android operating
  system, named with a feature called "Android Beam".  In addition, it
  is expected for the other mobile phones, running the other operating
  systems (e.g., iOS, etc.) to be equipped with NFC technology in the
  near future.

NEW
At the time of this writing, it had been used in devices such as mobile phones, running Android operating
  system, named with a feature called "Android Beam".  It was expected for the other mobile phones, running the other operating
  systems (e.g., iOS, etc.) to be equipped with NFC technology in the
  near future.

= Section 4.5 =

Per the Gen-ART review, the use of the term "meet" is confusing in this section. Please re-phrase.

[Ballot comment]
I apologize - I've read the document, but it doesn't seem like it contains enough information to allow a full implementation.

The document keeps talking about the fact that the range is limited to 10cm, and makes some security assertions from this - from the little that I understand about this technology (and I wasn't able to follow all the references), ISO 15693 tags using NDEF are now part of the NFC specification - these  work up to 1M. I have no idea if this protocol is supposed to work over that, but if so, 1M is greater than 10cm.

Also, I see you did respond to the OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-6lo-nfc-12-opsdir-lc-wu-2018-12-19/ -- thank you very much, Qin) , but there are things in these which don't seem fully addressed. As an example, Qin asked:
----
Section 3.4 said ” the MTU size in NFC LLCP MUST be calculated from the MIU
  value as follows:
                            MIU = 128 + MIUX.”
Can you provide formula to calculate MTU from MIU? Not clear how MTU is related to MIU?
---

You responded: "YH >> Actually, MIU is the same as MTU. Specifications in NFC forum use 'MIU', and we use 'MTU'. But these two has the same meaning."

I read version 13 of this document and had the exact same question -- how do I calculate the MTU from the MIU? If they really are the same thing (which I'm not sure they are), the document should state that, so readers can more easily implement.

[Ballot comment]
I apologize - I've read the document, but it doesn't seem like it contains enough information to allow a full implementation.

The document keeps talking about the fact that the range is limited to 10cm, and makes some security assertions from this - from the little that I understand about this technology (and I wasn't able to follow all the references), ISO 15693 tags using NDEF are now part of the NFC specification - these  work up to 1M. I have no idea if this protocol is supposed to work over that, but if so, 1M is greater than 10cm.

Also, I see you did respond to the OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-6lo-nfc-12-opsdir-lc-wu-2018-12-19/ ) , but there are things in these which don't seem fully addressed. As an example, Qin asked:
----
Section 3.4 said ” the MTU size in NFC LLCP MUST be calculated from the MIU
  value as follows:
                            MIU = 128 + MIUX.”
Can you provide formula to calculate MTU from MIU? Not clear how MTU is related to MIU?
---

You responded: "YH >> Actually, MIU is the same as MTU. Specifications in NFC forum use 'MIU', and we use 'MTU'. But these two has the same meaning."

I read version 13 of this document and had the exact same question -- how do I calculate the MTU from the MIU? If they really are the same thing (which I'm not sure they are), the document should state that, so readers can more easily implement.

[Ballot discuss]
I am unable to adequately review this document because the first normative reference and hence this DISCUSS is incomplete (ordinarily this would conflict with the DISCUSS guidelines, but I believe it is necessary in this case).

  [LLCP-1.3]
              "NFC Logical Link Control Protocol version 1.3", NFC Forum
              Technical Specification , March 2016.

Does not appear to be publicly available (the web site contains a single-page PDF which reads in part "To view the complete specification, go to http://nfc-forum.org/our- work/specifications-and-application-documents/specifications/nfc-forum- technical-specifications/. Complete the license agreement, and then download the specification."). Please supply an unencumbered specification and then I can rereview.


I have read S 3.4 repeatedly, but am unable to work out the mapping of an IPv6 datagram to LLCP. Please provide a diagram that shows how this works and then perhaps I can assist you with the text.

[Ballot discuss]
I am unable to adequately review this document because the first normative reference and hence this DISCUSS is incomplete.

  [LLCP-1.3]
              "NFC Logical Link Control Protocol version 1.3", NFC Forum
              Technical Specification , March 2016.

Does not appear to be publicly available (the web site contains a single-page PDF which reads in part "To view the complete specification, go to http://nfc-forum.org/our- work/specifications-and-application-documents/specifications/nfc-forum- technical-specifications/. Complete the license agreement, and then download the specification."). Please supply an unencumbered specification and then I can rereview.


I have read S 3.4 repeatedly, but am unable to work out the mapping of an IPv6 datagram to LLCP. Please provide a diagram that shows how this works and then perhaps I can assist you with the text.

[Ballot discuss]
Thanks to everyone who has worked on this document.

I generally agree with Benjamin's discuss points, and in particular agree with
his comment that it's kind of hard to figure out how all these pieces work
together. I have an additional issue that is somewhat related to some of the
points he raised, but which is (I think) not completely covered.

I'm really confused about what the purported privacy properties of this
protocol are. In section 4.3 (which I *think* talks about globally-routable IP
addresses, although this is a bit unclear), the document says:

  such an IID SHOULD guarantee a stable IPv6 address
  because each data link connection is uniquely identified by the pair
  of DSAP and SSAP included in the header of each LLC PDU in NFC

(Aside: this "should" is a simple statement of fact, not a described behavior of
the protocol, and so the use of RFC-2119-style all-caps is not appropriate.)

The presence of "a stable IPv6 address" inherently implies the ability to
track devices.

Then, in section 7, I find the following text:


  ...the short address of
  NFC link layer (LLC) is not generated as a physically permanent value
  but logically generated for each connection.  Thus, every single
  touch connection can use a different short address of NFC link with
  an extremely short-lived link.

This text seems to imply that addressing information is, in general, not stable,
which appears to flatly contradict the text in section 4.3.

Please clarify, in section 4.3, what the duration of stability of these
identifiers is.

[Ballot comment]
ID Nits reports:

  == Unused Reference: 'RFC4291' is defined on line 697, but no explicit
    reference was found in the text

---------------------------------------------------------------------------

§1:

>  IPv6 is an ideal internet
>  protocols owing to its large address space

Nit: "protocol"

[Ballot comment]
I agree with Benjamin about antenna size. Despite that I have enjoyed reading this document. I have some questions/comments that I would like to discuss before recommending publication of this document as an RFC:

In 3.2:

  The LLCP consists of Logical Link Control (LLC) and MAC Mapping.  The
  MAC Mapping integrates an existing RF protocol into the LLCP
  architecture.  The LLC contains three components, such as Link
  Management, Connection-oriented Transmission, and Connection-less
  Transmission.  The Link Management component is responsible for
  serializing all connection-oriented and connection-less LLC PDU
  (Protocol Data Unit) exchanges and for aggregation and disaggregation
  of small PDUs.  This component also guarantees asynchronous balanced
  mode communication and provides link status supervision by performing
  the symmetry procedure.

Can you translate the last sentence for somebody who is not an expert in this?

In 4.4:

  The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC
  network is can be accomplished via DHCPv6 Prefix Delegation

I think "is" before "can be" should be deleted above.

  ([RFC3633]).

In 4.5:

  o  When two or more NFC 6LNs(or 6LRs) meet, there are two cases.  One
      is that three or more NFC devices are linked with multi-hop
      connections, and the other is that they meet within a single hop
      range (e.g., isolated network).  In a case of multi-hops, all of
      6LNs, which have two or more connections with different neighbors,
      MAY be a router for 6LR/6LBR.  In a case that they meet within a
      single hop and they have the same properties, any of them can be a
      router.  When the NFC nodes are not of uniform category (e.g.,
      different MTU, level of remaining energy, connectivity, etc.), a
      performance-outstanding device can become a router.

The last sentence: how can 2 NFC nodes figure out which one has higher level or remaining energy, etc?

In 4.7:

  Therefore, IPv6 header compression in [RFC6282] MUST be implemented.
  Further, implementations MAY also support Generic Header Compression
  (GHC) of [RFC7400].

Will 2 NFC implementations interoperate if one of them supports GHC and the other one doesn't?
If they can't, then "MAY" seems to be too weak here.


In 4.8:

  IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is
  NOT RECOMMENDED in this document as discussed in Section 3.4.

You are using "NOT RECOMMENDED", which is "SHOULD NOT". Why is this not a "MUST NOT" and why implementation of FAR would be Ok if one node supports it and another one doesn't?

[Ballot comment]
I support Alissa's second Discuss point about the plan for fragmentation interoperation, and her third Discuss point about connecting unsuspecting devices to the Internet :-)

Other people have said this, but requiring MIUX would be awesome.

[Ballot discuss]
I support Benjamin's DISCUSS point about large antennas.

RFC 2119 specifies the keywords "RECOMMENDED" and "NOT RECOMMENDED." This document uses these in verb form ("RECOMMEND" and "NOT RECOMMEND"). Please change these instances so that the actual 2119 keywords are used.

= Section 4.8 =

I think the Gen-ART reviewer's question about fragmentation is unresolved. How is interoperability achieved if some nodes implement MIUX and not FAR, and some nodes implement FAR and not MIUX? It seems as though IPv6-over-NFC needs to be restricted to nodes that support one or the other (presumably MIUX).

= Section 5.1 and 7 =

Per the Gen-ART review, one of these sections needs to say something about how connecting to the Internet potentially changes the threat model for devices that were perhaps not originally envisioned to connect to the Internet.

[Ballot comment]
= General =

I agree with Benjamin that the marketing-type language in the document should be removed.

I wonder about the claims of security based on proximity in this document. Presumably attacks in which users are induced to tap their device against another node or terminal which has been compromised by an attacker are becoming more common as NFC becomes more common; adding IPV6 connectivity to the terminal stack surely broadens the potential damage done in such a case. This seems worth noting.

= Section 1 =

OLD
It has been used in devices such as mobile phones, running Android operating
  system, named with a feature called "Android Beam".  In addition, it
  is expected for the other mobile phones, running the other operating
  systems (e.g., iOS, etc.) to be equipped with NFC technology in the
  near future.

NEW
At the time of this writing, it had been used in devices such as mobile phones, running Android operating
  system, named with a feature called "Android Beam".  It was expected for the other mobile phones, running the other operating
  systems (e.g., iOS, etc.) to be equipped with NFC technology in the
  near future.

= Section 4.5 =

Per the Gen-ART review, the use of the term "meet" is confusing in this section. Please re-phrase.

[Ballot comment]
1) I agree with Benjamin's discuss point on sec 3.4: there seems to be a mismatch between the text and the figure that needs to be resolved or clarified before publication.

2)Use of normative language doesn't always seem quite appropriate, especially SHALL. Benjamin already identified some cases in section 3.3.

Here is an additional one in sec 4.1:
"The adaptation layer for IPv6 over NFC SHALL support neighbor
  discovery, stateless address auto-configuration, header compression,
  and fragmentation & reassembly."

Also this MAY in sec 5.2:
"In an isolated NFC-enabled device network,
  when two or more LRs MAY be connected with each other, and then they
  are acting like routers, the 6LR MUST ensure address collisions do
  not occur."

Please also check other occurrences.

3) I would have expected to see some discussion about the ability to potentially connect devices over an IP-gateway device to the Internet that were previously not designed to be connected to the Internet. However, maybe that's asked too much as that is certainly something that needs to be addressed by either a higher layer or the device system architecture as a whole.

[Ballot comment]
1) I agree with Benjamin's discuss point on sec 3.4: there seems to be a mismatch between the text and the figure that needs to be resolved or clarified before publication.

2)Use of normative language doesn't always seem quite appropriate, especially SHALL. Benjamin already identified some cases in section 3.3.

Here is an additional one in sec 4.1:
"The adaptation layer for IPv6 over NFC SHALL support neighbor
  discovery, stateless address auto-configuration, header compression,
  and fragmentation & reassembly."

Also this MAY in sec 5.2:
"In an isolated NFC-enabled device network,
  when two or more LRs MAY be connected with each other, and then they
  are acting like routers, the 6LR MUST ensure address collisions do
  not occur."

Please also check other occurrences.

3) I would have accepted to see some discussion about the ability to potentially connect devices over an IP-gateway device to the Internet that were previously not designed to be connected to the Internet. However, maybe that's asked too much as that is certainly something that needs to be addressed by either a higher layer or the device system architecture as a whole.

[Ballot comment]
1) I agree with Benjamin's discuss point on sec 3.4: there seems to be a mismatch between the text and the figure that needs to be resolved or clarified before publication.

2)Use of normative language doesn't always seem quite appropriate, especially SHALL. Benjamin already identified some cases in section 3.3.
Here is an additional one in sec 4.1:
"The adaptation layer for IPv6 over NFC SHALL support neighbor
  discovery, stateless address auto-configuration, header compression,
  and fragmentation & reassembly."
Also this MAY in sec 5.2:
"In an isolated NFC-enabled device network,
  when two or more LRs MAY be connected with each other, and then they
  are acting like routers, the 6LR MUST ensure address collisions do
  not occur."
Please also check other occurrences.

3) I would have accepted to see some discussion about the ability to potentially connect devices over an IP-gateway device to the Internet that were previously not designed to be connected to the Internet. However, maybe that's asked too much as that is certainly something that needs to be addressed by either a higher layer or the device system architecture as a whole.

[Ballot comment]
1) I agree with Benjamins discuss point on sec 3.4. There seems to be a mismatch between the text and the figure that needs to be resolved or clarified before publication.

2)Use of normative language doesn't always seem quite appropriate, especially SHALL. Benjamin already identified some cases in section 3.3.
Here is an additional one in sec 4.1:
"The adaptation layer for IPv6 over NFC SHALL support neighbor
  discovery, stateless address auto-configuration, header compression,
  and fragmentation & reassembly."
Also this MAY in sec 5.2:
"In an isolated NFC-enabled device network,
  when two or more LRs MAY be connected with each other, and then they
  are acting like routers, the 6LR MUST ensure address collisions do
  not occur."
Please also check other occurrences.

3) I would have accepted to see some discussion about the ability to potentially connect devices over an IP-gateway device to the Internet that were previously not designed to be connected to the Internet. However, maybe that's asked too much as that is certainly something that needs to be addressed by either a higher layer or the device system architecture as a whole.

[Ballot discuss]
In general, I'm worried that this document is so unreadable that I can't
give it a proper review.  I just don't have a clear picture of how all
the pieces fit together, and which pieces are new as opposed to reused
from other specifications.  That said, here are my notes as they stand
at present.

If I understand correctly, the statements about "distance of 10 cm or
less" and "safe" or "secure communications" apply only for usage
compliant with the relevant legal regulations.  We cannot expect
attackers to abide by such regulations, and large (directional) antennas
and/or high-power transmitters should be presumed to expand that
distance by some factor, in adversarial environments.

Section 4.3 should probably provide some guidance on choosing the PRF
F().  We are implicitly relying on RFC 7217 for a lot of things, some of
which 7127 doesn't even cover, and the suggested construction in RFC
7127 may not still be best practice.

I don't understand why MIUX is not mandatory (and thus we could get rid
of all the "FAR is NOT RECOMMENDED" stuff).  Is there known demand for
IPv6 over NFC on devices that cannot do MIUX?

Some section-by-section points as well:

Section 3.1

  peer mode is used for ipv6-over-nfc.  In addition, NFC-enabled
  devices can securely send IPv6 packets to any corresponding node on
  the Internet when an NFC-enabled gateway is linked to the Internet.

I don't see anything in the document that justifies the usage of
"securely".

Section 3.4

  When the MIUX parameter is encoded as a TLV option, the TLV Type
  field MUST be 0x02 and the TLV Length field MUST be 0x02.  The MIUX
  parameter MUST be encoded into the least significant 11 bits of the
  TLV Value field.  The unused bits in the TLV Value field MUST be set
  to zero by the sender and ignored by the receiver.  A maximum value

Either the MIUX occupies 11 bits and there are five unused bits to be
set to zero, or the four bits marked in the figure are 1011 and there is
only one unused bit (singular) to be marked as zero.  This needs to be
more clear, as right now I can't tell what's intended.

Section 4.4

How does a device know that the link-local address is a public address?

Section 4.5

  o  When an NFC-enabled device (6LN) is directly connected to a 6LBR,
      an NFC 6LN MUST register its address with the 6LBR by sending a

How does the device know that it's talking NFC to a 6LBR as opposed to
some non-border-router peer?

[Ballot comment]
A lot of this document reads like marketing material for NFC, which is a
bit off-putting in a technical specification.  (Some examples:
"outstanding performance", "NFC builds upon RFID systems by allowing
two-way communication between endpoints, where earlier systems such as
contactless smart cards were one-way only", "NFC also has the strongest
ability (e.g., secure communication distance of 10 cm) to prevent a
third party from attacking privacy", "NFC technology enables simple and
safe two-way interactions between electronic devices", "NFC's
bidirectional communication ability is ideal for establishing
connections with other technologies by the simplicity of touch", etc.)

Section 1

  Considering the potential for exponential growth in the number of
  heterogeneous air interface technologies, NFC would be widely used as
  one of the other air interface technologies, such as Bluetooth Low
  Energy (BT-LE), Wi-Fi, and so on.

nit: I think there's a word missing here or something, maybe "as widely
used".

Section 3

  NFC's bidirectional communication ability is ideal for establishing
  connections with other technologies by the simplicity of touch.  In

nit: other technologies, or other devices?

Section 3.2

There's no "IPv6 layer" in Figure 1.

Section 3.3

                      Address values between 10h and 1Fh SHALL be
  assigned by the local LLC to services registered by local service
  environment.  [...]

Is this duplicating a requirement from LLCP-1.3 or new to this spec?

Section 3.4

  MIUX extension parameter within the information field.  If no MIUX
  parameter is transmitted, the default MIU value is 128 bytes.

nit: I think this reads better (in context) without "default" here.

  When the MIUX parameter is encoded as a TLV option, the TLV Type
  field MUST be 0x02 and the TLV Length field MUST be 0x02.  The MIUX
  parameter MUST be encoded into the least significant 11 bits of the
  TLV Value field.  The unused bits in the TLV Value field MUST be set
  to zero by the sender and ignored by the receiver.  A maximum value

(Figure 2 is a little confusing because the '|' separator inside the
value field occupies a bit position; this type of diagram is frequently
laid out "double width", to allow a '| separator between each bit, with
'+' characters in the horizontal delimiting lines to mark off bit
boundaries.)

Also, you say "least significant bits" without specifying network byte
order.

nit: isn't this "The" maximum value?

  of the TLV Value field can be 0x7FF, and a maximum size of the MTU in
  NFC LLCP is 2176 bytes including the 128 byte default of MIU.

How can we use all 128 bytes of MIU when we need to spend four bytes on
the MIUX TLV?

Section 4.1

It's unclear to me what information I'm supposed to get from Figure 3
that differs from what was in Figure 1.

Section 4.2

  This document does NOT RECOMMEND using FAR over NFC link due to
  simplicity of the protocol and implementation.  [...]

nit: this isn't clear about what is simple.  ("If FAR is simple,
wouldn't that make it easy to implement and use?")

Section 4.3

  An NFC-enabled device (i.e., 6LN) performs stateless address
  autoconfiguration as per [RFC4862].  A 64-bit Interface identifier
  (IID) for an NFC interface is formed by utilizing the 6-bit NFC LLCP
  address (see Section 3.3).  In the viewpoint of address
  configuration, such an IID SHOULD guarantee a stable IPv6 address
  because each data link connection is uniquely identified by the pair
  of DSAP and SSAP included in the header of each LLC PDU in NFC.

(Just to check: these DSAP and SSAP are only unique within the context
of the current NFC pairing between two devices?)

The writing here is hard to follow -- I'm supposed to utilize the 6-bit
NFC LLCP address to form an IID (with nothing about how), but then we
see that IIDs for unicast are randomly generated (without using the LLCP
address), and only finally at the end do we mention the RFC 7217 PRF
(and not even by name!)

Section 4.4

Show me where the "Universal/Local" bit is, in the figure.

Expand 6LBR (and 6LR) on first use, and/or have a terminology section
that mentions that familiarity with the 6LoWPAN RFCs is assumed.

Section 4.5

      accordingly.  In addition, if DHCPv6 is used to assign an address,
      Duplicate Address Detection (DAD) is not necessary.

Not necessary in the DHCPv6 server or some other element?

  o  When two or more NFC 6LNs(or 6LRs) meet, there are two cases.  One
      is that three or more NFC devices are linked with multi-hop
      connections, and the other is that they meet within a single hop

I thought we said that NFC was a two-party thing only.  How are we
getting multi-hop connections?  If I assume that this is talking about
the IPv6 layer, how do we guarantee that only NFC-capable devices are
participating in the IPv6 network?

      router.  When the NFC nodes are not of uniform category (e.g.,
      different MTU, level of remaining energy, connectivity, etc.), a
      performance-outstanding device can become a router.  [...]

This seems rather under-specified.

Section 4.9

A link to Section 4.6.1 of RFC 4861 and a note that the field
descriptions are largely copied therefrom would be helpful.

Section 5.1

This section is laying out the physical mechanics of how a NFC node can
be connected to the Internet, but does not say why this is "typical" or
what the NFC node would be talking to on the Internet.

  One of the key applications of using IPv6 over NFC is securely
  transmitting IPv6 packets because the RF distance between 6LN and
  6LBR is typically within 10 cm.  If any third party wants to hack
  into the RF between them, it must come to nearly touch them.

Or use a big and ungainly high-gain antenna/illegal transmit power, right?

Section 5.2

This example does a little better than the previous one at conveying
what might motivate such a topology, but it's still pretty vague.

What is "outstanding performance"?  This doesn't seem actionable.

Section 7

  IPv6-over-NFC is, in practice, not used for long-lived links for big
  size data transfer or multimedia streaming, but used for extremely
  short-lived links (i.e., single touch-based approaches) for ID
  verification and mobile payment.  This will mitigate the threat of
  correlation of activities over time.

This mitigation only occurs if the IID is freshly generated for each
link, which isn't mentioned until the next paragraph, so it's an
unsupported claim at this point in the text.

  IPv6-over-NFC uses an IPv6 interface identifier formed from a "Short
  Address" and a set of well-known constant bits (such as padding with
  '0's) for the modified EUI-64 format.  However, the short address of

nit: Is the zero-padding really a "such as" or just a fact, given the
protocol specification?

  NFC link layer (LLC) is not generated as a physically permanent value
  but logically generated for each connection.  Thus, every single
  touch connection can use a different short address of NFC link with

nit: I don't think this is "can use"; I think this is "uses".

  an extremely short-lived link.  This can mitigate address scanning as
  well as location tracking and device-specific vulnerability
  exploitation.

These last two seem to have high overlap with the "correlation of
activities over time" from the previous paragraph.

  Thus, this document does not RECOMMEND sending NFC packets over the
  Internet or any unsecured network.

I don't see any preceding argument that leads into or supports this
claim; why is the word "thus" present?
Also, such a recommendation seems like it should be more prominently
made near the start of the document and not relegated to the security
considerations.

This document also does not give any indication of what might be
considered to be a "secure" network.  Note that per the RFC 3552 threat
model, we generally do not place any trust in the network.

Section 9.2

Isn't the whole point of this work that you are doing IPv6 over NFC?
How do you not need to implement NFC in order to implement this?

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational,
Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in
the title page header?

A. draft-ietf-6lo-nfc-10 draft is a 'standards track' document. The intended status is indicated
in the document header. Since it is defining ipv6-over NFC adaptation layer, it is standard track.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a
Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  Near field communication (NFC) is a set of standards for smartphones
  and portable devices to establish radio communication with each other
  by touching them together or bringing them into proximity, usually no
  more than 10 cm. The NFC technology has been widely implemented and available
  in mobile phones, laptop computers, and many other devices.  This
  document describes how IPv6 is transmitted over NFC using 6LowPAN
  techniques.

  Considering the potential for exponential growth in the number of
  heterogeneous air interface technologies, NFC would be widely used as
  one of the other air interface technologies, such as Bluetooth Low
  Energy (BT-LE), Wi-Fi, and so on.  Each of the heterogeneous air
  interface technologies has its own characteristics, which cannot be
  covered by the other technologies, so various kinds of air interface
  technologies would co-exist together.  Therefore, it is required for
  them to communicate with each other. Running IPv6 over the various low
  power L2 technologies with the modified 6lowpan stack ensures interoperability
  among the devices with various heterogeneous air interfaces.




Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular
points or were there decisions where the consensus was particularly rough?

A. This document has been revised several times based on working group comments. It has been reviewed by
  several experienced 6lo working group members including Pascal Thubert and Dave Thaler  who have been
  designated reviewers of this document. It has has also received shepherd's comments and went through two
  WGLC ( one short and one regular one).

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their
plan to implement the specification? Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?
In the case of a Media Type review, on what date was the request posted?

A.

The document has been reviewed and discussed by many 6lo experts in the WG including Pascal Thubert, Carsten Bormann,
Dave Thaler, Samita Chakrabarti, Gabriel Montenegro, James Woodyatt, Alex Petrescue, Michael Richardson.

An implementation of 6lo-NFC exists and they participated on a 6lo plugtests.
The document effort is also socialized with NFC-Forum and they are well aware this document.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd: Carles Gomez, Responsible Area Director: Suresh Krishnan


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version
of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A. Document shepherd has reviewed the -09 version of the document and provided comments. The -10
  version of 6lo-nfc document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been
performed?

A. The document is ready for IESG review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took
place.

A. Not applicable.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the
Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail
those concerns here.

A.  It has been reviewed by a number of WG members and the shepherd. It is ready to advance.




(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with
the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

A. An IPR Disclosure has been filed and recorded in IETF page
  https://datatracker.ietf.org/ipr/2653/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and
conclusion regarding the IPR disclosures.
A. Yes. There is no objection at the WG about the IPR filed for the document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the WG as a whole understand and agree with it?

A. The working group as a whole understands and agrees with the progress of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the
areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate
email because this questionnaire is publicly available.)

A. No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough;
this check needs to be thorough.

No issues found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type,
and URI type reviews.

A. Not Applicable.

(13) Have all references within this document been identified as either normative or informative?

A. Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an
unclear state? If such normative references exist, what is the plan for their completion?
A. No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references
to support the Area Director in the Last Call procedure.

A. None.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the
title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the document where the relationship of
this document to the other RFCs is discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No. This document will not update any base 6lo documents or  existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to
its consistency with the body of the document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A. The document does not request any IANA change.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public
guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A. Not Applicable

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.(1) What type of
RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

A. Not Applicable

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-6lo-nfc-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-12-24):

From: The IESG
To: IETF-Announce
CC: 6lo-chairs@ietf.org, samitac.ietf@gmail.com, draft-ietf-6lo-nfc@ietf.org, 6lo@ietf.org, Samita Chakrabarti , suresh@kaloom.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Transmission of IPv6 Packets over Near Field Communication) to Proposed Standard


The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document: -
'Transmission of IPv6 Packets over Near Field Communication'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-12-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Near field communication (NFC) is a set of standards for smartphones
  and portable devices to establish radio communication with each other
  by touching them together or bringing them into proximity, usually no
  more than 10 cm.  NFC standards cover communications protocols and
  data exchange formats, and are based on existing radio-frequency
  identification (RFID) standards including ISO/IEC 14443 and FeliCa.
  The standards include ISO/IEC 18092 and those defined by the NFC
  Forum.  The NFC technology has been widely implemented and available
  in mobile phones, laptop computers, and many other devices.  This
  document describes how IPv6 is transmitted over NFC using 6LowPAN
  techniques.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2653/

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational,
Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in
the title page header?

A. draft-ietf-6lo-nfc-10 draft is a 'standards track' document. The intended status is indicated
in the document header. Since it is defining ipv6-over NFC adaptation layer, it is standard track.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a
Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  Near field communication (NFC) is a set of standards for smartphones
  and portable devices to establish radio communication with each other
  by touching them together or bringing them into proximity, usually no
  more than 10 cm. The NFC technology has been widely implemented and available
  in mobile phones, laptop computers, and many other devices.  This
  document describes how IPv6 is transmitted over NFC using 6LowPAN
  techniques.

  Considering the potential for exponential growth in the number of
  heterogeneous air interface technologies, NFC would be widely used as
  one of the other air interface technologies, such as Bluetooth Low
  Energy (BT-LE), Wi-Fi, and so on.  Each of the heterogeneous air
  interface technologies has its own characteristics, which cannot be
  covered by the other technologies, so various kinds of air interface
  technologies would co-exist together.  Therefore, it is required for
  them to communicate with each other. Running IPv6 over the various low
  power L2 technologies with the modified 6lowpan stack ensures interoperability
  among the devices with various heterogeneous air interfaces.




Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular
points or were there decisions where the consensus was particularly rough?

A. This document has been revised several times based on working group comments. It has been reviewed by
  several experienced 6lo working group members including Pascal Thubert and Dave Thaler  who have been
  designated reviewers of this document. It has has also received shepherd's comments and went through two
  WGLC ( one short and one regular one).

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their
plan to implement the specification? Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?
In the case of a Media Type review, on what date was the request posted?

A.

The document has been reviewed and discussed by many 6lo experts in the WG including Pascal Thubert, Carsten Bormann,
Dave Thaler, Samita Chakrabarti, Gabriel Montenegro, James Woodyatt, Alex Petrescue, Michael Richardson.

An implementation of 6lo-NFC exists and they participated on a 6lo plugtests.
The document effort is also socialized with NFC-Forum and they are well aware this document.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd: Samita Chakrabarti, Responsible Area Director: Suresh Krishnan


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version
of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A. Document shepherd has reviewed the -09 version of the document and provided comments. The -10
  version of 6lo-nfc document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been
performed?

A. The document is ready for IESG review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took
place.

A. Not applicable.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the
Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail
those concerns here.

A.  It has been reviewed by a number of WG members and the shepherd. It is ready to advance.




(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with
the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

A. An IPR Disclosure has been filed and recorded in IETF page
  https://datatracker.ietf.org/ipr/2653/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and
conclusion regarding the IPR disclosures.
A. Yes. There is no objection at the WG about the IPR filed for the document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the WG as a whole understand and agree with it?

A. The working group as a whole understands and agrees with the progress of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the
areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate
email because this questionnaire is publicly available.)

A. No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough;
this check needs to be thorough.

No issues found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type,
and URI type reviews.

A. Not Applicable.

(13) Have all references within this document been identified as either normative or informative?

A. Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an
unclear state? If such normative references exist, what is the plan for their completion?
A. No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references
to support the Area Director in the Last Call procedure.

A. None.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the
title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the document where the relationship of
this document to the other RFCs is discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No. This document will not update any base 6lo documents or  existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to
its consistency with the body of the document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A. The document does not request any IANA change.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public
guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A. Not Applicable

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.(1) What type of
RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

A. Not Applicable