Re: [radext] Update RFC 6929 in draft-ietf-radext-radius-fragmentation

[Stefan Winter <[e-mail]>]

Hello,

with my shiny new chair hat on:

>> While it is true that an implementer of 6929 does not need to see this
>> document, it is also true that this document is effectively allocating a
>> bit from a structure that is in that document.  If this document does
>> not update 6929, then it is possible that the next document to update
>> that structure will fail to notice this and allocate the same bit for a
>> different purpose.
> 
>   I hope we're all smart enough to remember that the bit is allocated.
> If we're not... the WG should be shut down.

I believe it's a bad idea to rely on collective memory or a mailing list
archive.

So, regardless of what the consensus will be: try an "Updates" or not;
create an IANA registry or not - the fact that a loosely-knit
relationship to RFC6929 exists, and where the pitfalls are, should be
reflected inside the draft itself.

As for where - I think it helps to keep in mind that that there will be
numerous rounds of reviewing going on after the document has cleared WGLC.

In particular, the Operations Area will conduct an ops-dir review as
part of the IETF LC. There are very specific questions in the ops-dir
review template, one of which is:

"Are there any coexistence issues?"

The probability that an ops-dir reviewer will pick up the T-Bit
allocation coexistence issue during his reading are very high
(especially if the proto write-up mentions this as one of the
contentious points :-) ); so if that issue is not explicitly documented,
it will probably surface at that point, and we'll need to deal with it.

We can of course wait for that to happen, but I'd rather preempt such a
useless extra round and fix the issue in the draft right now.

Another question in the ops-dir review is

"Is an operational considerations and/or manageability section part of
the document?"

I believe the best way forward is to add such a section to the draft (it
could be a sub-section of Introduction, or be a section of its own). The
section would document what was argued on the mailing list, where the
pitfalls are, and that an "Updates" would be a reasonable possiblity to
avoid them if allowed by process.

With that text in the document, the WG can then try to use Updates or
not - and the reason for doing so can then be found in the document
itself. If the actual Updates relationship later doesn't fly, the text
highlighting the issue will at least still be in there - and not in
someone's brain or deep down in the ML archives. I realise that the text
then wouldn't necessarily be found by someone implementing a follow-up
spec to RFC6929 due to lack of an Updated-By, but chances are at least
way better.

(And as an individual: if we have an Operations/Manageability section
anyway at that point - wouldn't it be a good idea to move the "formal
violation of RFC2865" into that section as well? )

Greetings,

Stefan Winter

>> I believe that this update relationship needs to be retained.
> 
>   It may be useful, but IETF process may forbid it.
> 
>   Alan DeKok.
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66