DNS Name Server Identifier (NSID) Option
draft-ietf-dnsext-nsid-02

Note: This ballot was opened for revision 02 and is now closed.

Lars Eggert No Objection

Section 3.4., paragraph 3:
>    By definition, a resolver that requests NSID responses also supports
>    EDNS, so a resolver that requests NSID responses can also use the
>    "sender's UDP payload size" field of the OPT pseudo-RR to signal a
>    receive buffer size large enough to make truncation unlikely.

  Even thought this may make truncation unlikely, long NSIDs may still
  increase the likelihood of fragmentation, with the corresponding
  decrease of reliability. May want to add a sentence on that here.

(Jari Arkko; former steering group member) Yes

(Lisa Dusseault; former steering group member) Yes

(Mark Townsley; former steering group member) Yes

(Sam Hartman; former steering group member) Yes

(Chris Newman; former steering group member) No Objection

(Cullen Jennings; former steering group member) No Objection

(Dan Romascanu; former steering group member) No Objection

(David Ward; former steering group member) No Objection

(Jon Peterson; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

Section 3.1 describes eight alternatives for the payload of the nsid option.  Immediately below,
the text provides advantages and disadavantages for six of the eight options.  No advantages or
diadvantages are given for the remaining options (a digitally signed blob or an encrypted blob).
I would like to see brief descriptions of the utility of these mechanisms, particularly with respect
to the content of the associated plaintext.