Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
RFC 6408
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
(Dan Romascanu; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
You need to remove the citation form the Abstract since this is standalone text.
(David Harrington; former steering group member) No Objection
I support Wes's concerns based on tsvdir review, and also support Ralph's request for DNS review.
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
You have the following two ABNF expressions:
iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM
iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM
You could shorten them to:
iana-registered-service =/ aaa-service
iana-registered-protocol =/ aaa-protocol
If you want to be precise, instead of:
appln-id = 1*DIGIT
you should probably have:
appln-id = 1*26DIGIT
For the record, I don't think it's worth addressing the ABNF issue that Stephen has in his comment, but if you insist on doing so, this would solve the problem:
reg-prefix = ("X" (ALPHA / DIGIT / "+" / ".") ) /
(("A" - "W" / "Y" / "Z") ALPHANUMSYM)
iana-registered-service = ALPHA / (reg-prefix *30ALPHANUMSYM)
iana-registered-protocol = ALPHA / (reg-prefix *30ALPHANUMSYM)
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) (was Discuss) No Objection
(Robert Sparks; former steering group member) No Objection
Since the numeric part of aaa+apNNNN is intended to be parsed and compared against application IDs: 1) your syntax allows for arbitrarily long digit strings after aaa+ap. You are expecting that your registration rules will never let a name with a digit string that can't be parsed as a 32 bit unsigned get registered, but that won't keep it from showing up on the wire. (For that matter, changing the syntax wouldn't either). You might want to warn implementers that they could be handed something too large. Similarly, someone could populate a DNS record with something looking like aaa+ap02, or aaa+ap002. You probably don't want those to be parsed and treated the same as aaa+ap2, right? 2) This doesn't change the registration rules for 3958. Someone only needs an RFC (on any track) to register an aaa+ap666 (or any other number that's not backed up by a corresponding codepoint in <http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml> at the Application IDs table. You're counting, (I think), on pattern matching from whichever stream-editor/reviewer to recognize that such a registration needs review against the registries created by 3588. Am I missing something else that would make this unlikely to fail to happen?
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
Can the different abnf productions here really be distinguished?
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
Seems like ALPHA *31ALPHASYMNUM does allow starting with "x-"
so there's no way to know if an "x-foo" is iana-registered or not based
on the abnf above. (Or is there some 1st matching rule I don't know?)
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) (was Discuss) No Objection