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

[Alejandro Perez Mendez <[e-mail]>]

El 24/03/14 15:22, Stefan Winter escribió:
> 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? )

I think it is a good idea to have such a section, specially is you think
it will be requested by ops-dir reviewers if not present. I would place
it as section 10, right before "Security considerations" section,
instead of in the Introduction section, to avoid basing the explanations
on something that has not been described yet.

I also think that the "formal violation..." discussion should be moved
here. We could also include the "proxying based on User-Name"
restriction too.

Regards,
Alejandro
>
> 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
>>
>
>
>
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext