Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-04.txt

From: Sandra Murphy <[email-masked]>
Date: Tue, 2 Jun 2015 09:38:37 -0400

Steve, Richard, I don't know if you have noticed, but publication has already been requested for this draft.

I don't regard this issue as critical enough to delay publication.  Of course, If the routing AD has comments he wishes to have addressed before he pushes the draft into IETF Last Call, there would be an opportunity to address it as needed then.  Otherwise, it can be addressed as needed as part of IETF Last Call.

Obviously, this issue must exist in any RFC that provides an example of base64 encoded material, due to the RFC line length limit.  I've looked at some of the (many!) other RFCs that refer to rfc4648.  Some say nothing about the fact that line breaks are present in the example, some add a brief phrase about the RFC publication limits, something like Steve's suggestion.  We can temper the need with knowing that history.

--Sandy, speaking as wg co-chair

On May 28, 2015, at 5:34 PM, Stephen Kent <[email-masked]> wrote:

> Richard,
> 
> Sorry to be late replying to your message, but I just returned from a vacation trip.
> 
> I think we can do one of two things to address the problem you correctly
> identified:
>    1- either say that the example in the doc has been formatted for
>       the RFC, and that no LFs are permitted
>    2- adopt your text to explicitly override the "no NL" rule in 4648.
> 
> Steve
> 
>> Hi Geoff, Sam, George, and Steve,
>> 
>> I spotted a bug in this draft:  Section 2.1 refers to Base64 encoding,
>> defined in RFC4648 Section 4.  RFC4648 Section 3.1 says:
>> 
>>    Implementations MUST NOT add line feeds to base-encoded data unless
>>    the specification referring to this document explicitly directs base
>>    encoders to add line feeds after a specific number of characters.
>> 
>> Section 2.1 doesn't say anything about adding newlines to the Base64
>> string, yet the example in Section 2.3 contains embedded newlines every
>> 57 characters.
>> 
>> Rather than fix the example in Section 2.3 to conform to the current
>> Section 2.1, I think it would be better to permit newlines in the Base64
>> data:
>> 
>>       3)  a subjectPublicKeyInfo [RFC5280] in DER format [X.509],
>>           encoded in Base64 (see Section 4 of [RFC4648]).  To avoid
>>           long lines, a <CRLF> or <LF> line break MAY be inserted into
>>           the Base64 encoded string every 40 or more characters.
>> 
>> The choice of 40 is arbitrary; I just didn't want an implementation to
>> be ridiculous and add a newline after only one or a few characters.
>> 
>> I wouldn't mind changing it to "MUST be inserted every 40 to 76
>> characters" to make it possible to write a parser with fixed-length line
>> buffers.
>> 
>> (I also spotted a few typos, sent off-list.)
>> 
>> -Richard
>> 
>> 
>> On 2015-05-15 01:10, [email-masked] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>  This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.
>>> 
>>>         Title           : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
>>>         Authors         : Geoff Huston
>>>                           Samuel Weiler
>>>                           George Michaelson
>>>                           Stephen Kent
>>> 	Filename        : draft-ietf-sidr-rfc6490-bis-04.txt
>>> 	Pages           : 9
>>> 	Date            : 2015-05-14
>>> 
>>> Abstract:
>>>    This document defines a Trust Anchor Locator (TAL) for the Resource
>>>    Public Key Infrastructure (RPKI).  This document obsoletes RFC6490 by
>>>    adding support for multiple URIs in a TAL.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/
>>> 
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-04
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6490-bis-04
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> sidr mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>> 
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Tue, 02 Jun 2015 14:40:40 -0400

Sandy,

No I had not noticed that the doc completed WGLC, but I guess I was on 
vacation at
that time.

If my co-authors and you and Chirs, and Alvaro agree, I'll suggest that 
Richard raise the issue during IETF last call as a way to letting 
everyone know that we plan to make this
change before publication as an RFC. OK?

Steve

p.s. if other docs have failed to be explicit about this that doesn't 
mean we can't
do a better job, right? Also, I'm curious ton know whether RPs are 
ignoring LFs or
if they assumed the formatting was purely an artifact of RFC 
publication  constraints.

---

From: David Mandelberg <[email-masked]>
Date: Tue, 02 Jun 2015 15:08:46 -0400

On 2015-06-02 14:40, Stephen Kent wrote:
> Also, I'm curious ton know whether RPs are
> ignoring LFs or

All of the TALs I've ever seen have had line breaks in the Base64. I 
haven't checked if they're CRLF or LF. Rpstir ignores either type of 
line break within the Base64.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 2 Jun 2015 16:20:02 -0400

On Jun 2, 2015, at 2:40 PM, Stephen Kent <[email-masked]> wrote:

> Sandy,
> 
> No I had not noticed that the doc completed WGLC, but I guess I was on vacation at
> that time.
> 
> If my co-authors and you and Chirs, and Alvaro agree, I'll suggest that Richard raise the issue during IETF last call as a way to letting everyone know that we plan to make this

There is no way that I or any other wg chair has any business trying to initiate/stop a IETF Last Call comment!

If you are attempting to alert the authors to expect a comment, that's good, but does not need wg chair approval.

So not sure what you are asking, but I think you are OK.

> 
> Steve
> 
> p.s. if other docs have failed to be explicit about this that doesn't mean we can't
> do a better job, right?

Nope.  Might be an indication of what the community has been comfortable with, that's all.

For those that are explicit, seeing how they state things might help, especially being consistent.

> Also, I'm curious ton know whether RPs are ignoring LFs or
> if they assumed the formatting was purely an artifact of RFC publication  constraints.

That would indeed be interesting data!!

--Sandy, speaking as one of the co-chairs

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 2 Jun 2015 19:35:51 -0400

And I said in the message to which you replied:

> Otherwise, it can be addressed as needed as part of IETF Last Call.

--Sandy