Subject: [Pana] [Fwd: draft-ietf-pana-pana-18.txt updated by Amanda Baber]

From: Mark Townsley <[email-masked]>
Date: Wed, 26 Sep 2007 05:33:20 +0200

We need answers and verification for these actions before progressing. 
It's probably better to have as many eyeballs double-checking this in 
the WG as possible.

Thanks,

- Mark

-------- Original Message --------
Subject: 	draft-ietf-pana-pana-18.txt updated by Amanda Baber
Date: 	Tue, 25 Sep 2007 16:38:04 -0400
From: 	DraftTracker Mail System <[email-masked]>
To: 	[email-masked]

Please DO NOT reply on this email.

I-D: draft-ietf-pana-pana-18.txt
ID Tracker URL: https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=10187&rfc_flag=0
 A new comment added by Amanda Baber

IANA Last Call comments:

IANA has questions.

In 10.3.1 the document says:

AVP Code 0 is not used.

Does this mean that code 0 cannot be assigned, or only that this code
isn't defined in this document but can be assigned by IANA?

In addition, the actual registry contents aren't fully
declared in the IANA Considerations section nor in the
previous sections. IANA has guessed on the contents of
the registries based on the available information.

Action 1

Upon approval of this document, the IANA will make the following assignments
in the "PORT NUMBERS" registry located at
http://www.iana.org/assignments/port-numbers
sub-registry "WELL KNOWN PORT NUMBERS"

Keyword Decimal Description References
------- ------- ----------- ----------
pana [tbd]/udp PANA Port [RFC-pana-pana-18]

Action 2

Upon approval of this document, the IANA will create the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
Initial contents of this registry will be the following sub-registries.

Action 3

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "Message Types"
Allocation Policy: IETF Consensus
Initial contents of this sub-registry will be:

Value Req/Ans Abbrev Name Reference
----- ------ ------ -------- ---------
0 available for assignment [RFC-pana-pana-18]
1 Req PCI PANA-Client-Initiation [RFC-pana-pana-18]
2 Req PAR PANA-Auth-Request [RFC-pana-pana-18]
2 Ans PAN PANA-Auth-Answer [RFC-pana-pana-18]
3 Req PTR PANA-Termination-Request [RFC-pana-pana-18]
3 Ans PTA PANA-Termination-Answer [RFC-pana-pana-18]
4 Req PNR PANA-Notification-Request [RFC-pana-pana-18]
4 Ans PNA PANA-Notification-Answer [RFC-pana-pana-18]
5-65519 available for assignment [RFC-pana-pana-18]
65520-65535 experimental values [RFC-pana-pana-18]

Action 4

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "Message Flags"
Allocation Policy: Standards Action
Initial contents of this sub-registry will be:

Bit Code Description Reference
--- ---- ----------- ---------
0 R Request [RFC-pana-pana-18]
1 S Start [RFC-pana-pana-18]
2 C Complete [RFC-pana-pana-18]
3 A re-Authentication [RFC-pana-pana-18]
4 P Ping [RFC-pana-pana-18]
5 I IP Reconfiguration [RFC-pana-pana-18]
6-15 available for assignment [RFC-pana-pana-18]

Action 5

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "AVP Codes"
Allocation Policy: Expert Review with Specification Required

IESG NOTE: Expert required

Initial contents of this sub-registry will be:

Code Attribute Name Reference
---- ---------------- ---------
0 ??? [RFC-pana-pana-18]
1 AUTH [RFC-pana-pana-18]
2 EAP-Payload [RFC-pana-pana-18]
3 Integrity-Algorithm [RFC-pana-pana-18]
4 Key-Id [RFC-pana-pana-18]
5 Nonce [RFC-pana-pana-18]
6 PRF-Algorithm [RFC-pana-pana-18]
7 Result-Code [RFC-pana-pana-18]
8 Session-Lifetime [RFC-pana-pana-18]
9 Termination-Cause [RFC-pana-pana-18]
10-65535 Available for assignment [RFC-pana-pana-18]

Action 6

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "AVP Flags"
Allocation Policy: Standards Action
Initial contents of this sub-registry will be:

Bit Code Description Reference
--- ---- ----------- ---------
0 V Vendor [RFC-pana-pana-18]
1-15 Available for Assignment [RFC-pana-pana-18]

Action 7

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "Result-Code AVP Values"
Allocation Policy: IETF Consensus
Initial contents of this sub-registry will be:

Value Meaning Reference
----- ------------- -----------
0 PANA_SUCCESS [RFC-pana-pana-18]
1 PANA_AUTHENTICATION_REJECTED [RFC-pana-pana-18]
2 PANA_AUTHORIZAZTION_REJECTED [RFC-pana-pana-18]
3-4294967295 Available for Assignment [RFC-pana-pana-18]

Action 8

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "Termination-Cause AVP Values"
Allocation Policy: IETF Consensus
Initial contents of this sub-registry will be:

Value Meaning Reference
----- ------------- -----------
0 Available for Assignment [RFC-pana-pana-18]
1 LOGOUT [RFC-pana-pana-18]
2-3 Available for Assignment [RFC-pana-pana-18]
4 ADMINISTRATIVE [RFC-pana-pana-18]
5-7 Available for Assignment [RFC-pana-pana-18]
8 SESSION_TIMEOUT [RFC-pana-pana-18]
9-4294967295 Available for Assignment [RFC-pana-pana-18]

We understand the above to be the only IANA Actions for this document.

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 27 Sep 2007 12:31:13 +0300

> isn't defined in this document but can be assigned by IANA?

I think we meant to keep 0 as reserved. I don't know why though...

> Keyword Decimal Description References

Same here, right? 0 is reserved, not meant to be allocated.

> Bit Code Description Reference

Reserved.

> Bit Code Description Reference

Not sure why we needed such a huge space.

> Initial contents of this sub-registry will be:

Same here: too big.

Can we at least shrink these two down to 16 bits?

Alper

---

From: James Carlson <[email-masked]>
Date: Thu, 27 Sep 2007 08:39:19 -0400

> I think we meant to keep 0 as reserved. I don't know why though...

I'd suggest leaving 0 reserved for most enumerations, just because
zero is the result of a common coding error.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 27 Sep 2007 10:13:25 -0400

> Not sure why we needed such a huge space.

This is just because Result-Code AVP value is of type Unsigned32.

> > 9-4294967295 Available for Assignment [RFC-pana-pana-18]

Again this is because Termination-Cause AVP value is of type
Enumerated which is derived from Integer32.

> Can we at least shrink these two down to 16 bits?

Since we are reusing data types defined in RFC 3588 and the least
integer length is 32-bit in RFC 3588, we don't have a 16-bit integer
data type for PANA unless we define it the PANA specification.  Also,
if we define 16-bit interger types in the PANA specification, then we
need to consider padding issues for those types.  (In RFC 3588,
all data types except for String align naturally to 4-octet boundary,
and thus a padding rule is defined only for String data type.)

My personal take is to keep the current data types and resulting IANA
actions on these two.

Yoshihiro Ohba