Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol
RFC 5458

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

(Mark Townsley; former steering group member) Yes

Yes ()
No email
send info

(Chris Newman; former steering group member) No Objection

No Objection ()
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ()
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ()
No email
send info

(David Ward; former steering group member) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection (2009-01-15)
No email
send info
Appendix A talks about modeling DBV link layer security with a 
number of modules, including a security policy database (SPD)
that may resemble a similar functionality in IPsec.

I wanted to note that traditionally link layer security has been
operated using far simpler policy mechanisms that exists at the
IP layer. Typically, security is either applied or not applied;
some form of algorithm selection is of course needed for algorithm
agility.There are many good reasons for these simple policies, e.g.,
avoiding complexity, the endpoints stay the same (host -> AP),
the endpoints are known to support the mandatory link layer security
features, etc.

I would suggest that the same may apply for DVB as well.

(Magnus Westerlund; former steering group member) No Objection

No Objection ()
No email
send info

(Pasi Eronen; former steering group member) No Objection

No Objection ()
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ()
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2009-01-12)
No email
send info
  Please consider the comments made by Vijay Gurbani in the Gen-ART
  Review that he posted on 28-Nov-2008.

  In S4, requirements 2-5 have a normative strength of OPTIONAL.
  While I am not trying to second guess the decision reached
  by the WG in assigning this normative strength, I am just
  curious why the strength was not at least a SHOULD (or
  RECOMMENDED)?  These seem like good requirements to have,
  and keeping them OPTIONAL effectively implies that very
  few vendors, if any, will implement them.

  In Abstract: s/a range of services/a variety of services
    (reason: "range" is used in the line above as well.)

(Tim Polk; former steering group member) No Objection

No Objection ()
No email
send info