Subject: [sidr] draft-ietf-sidr-roa-format ASN1-format

From: "Spies, Sebastian Martin" <[email-masked]>
Date: Thu, 31 Mar 2011 11:47:00 -0400

The AFI of ROAIPAddress (defined in 3. The ROA eContent of draft-ietf-sidr-roa-format) is of type OCTET STRING (SIZE (2..3)). For which reason is it necessary to have a variable AFI size? We are having just two values 0001 and 0002 and it is unlikely to see new address families at a count that exceeds 2^16. So why should there be a third byte?

----
Sebastian Spies

---

From: Andy Newton <[email-masked]>
Date: Thu, 31 Mar 2011 17:02:53 +0000

> The AFI of ROAIPAddress (defined in 3. The ROA eContent of draft-ietf-sidr-roa-format) is of type OCTET STRING (SIZE (2..3)). For which reason is it necessary to have a variable AFI size? We are ha…

I believe this is represented the same way as it is in RFC 3779. Section 2.3.3:

   IPAddressFamily     ::= SEQUENCE {    -- AFI & optional SAFI --
      addressFamily        OCTET STRING (SIZE (2..3)),
      ipAddressChoice      IPAddressChoice }

-andy

---

From: Rob Austein <[email-masked]>
Date: Fri, 01 Apr 2011 08:14:17 +0200

At Thu, 31 Mar 2011 17:02:53 +0000, Andy Newton wrote:
> > The AFI of ROAIPAddress (defined in 3. The ROA eContent of
> > draft-ietf-sidr-roa-format) is of type OCTET STRING (SIZE
> > (2..3)). For which reason is it necessary to have a variable AFI
> > size? We are having just two values 0001 and 0002 and it is
> > unlikely to see new address families at a count that exceeds
> > 2^16. So why should there be a third byte?
> 

Yes, that byte is the optional SAFI.  At least, that's how all the
running code of which I'm aware interprets it.  At present we're only
certifying AFIs 1 and 2 with null SAFI, hence the text in section 3.3.
The text should say that the third byte is the SAFI.  Good catch.